The ATtiny3217 Curiosity Nano Evaluation Kit is a hardware platform to evaluate microcontrollers in the tinyAVR 1series. This board has the ATtiny3217 microcontroller (MCU) mounted.
Supported by Atmel Studio and Microchip MPLAB® X Integrated Development Environments (IDEs), the board
provides easy access to the features of the ATtiny3217 to explore how to integrate the device into a custom design.
The Curiosity Nano series of evaluation boards include an on-board debugger. No external tools are necessary to
program and debug the ATtiny3217.
• MPLAB® X IDE and Atmel Studio - Software to discover, configure, develop, program, and debug Microchip
microcontrollers.
• ATtiny3217 website - Find documentation, sample, and purchase microcontrollers.
• ATtiny3217 Curiosity Nano website - Kit information, latest user guide and design documentation.
7.3.Curiosity Nano Base for Click boards™...................................................................................... 33
7.4.Disconnecting the On-board Debugger......................................................................................34
7.5.Getting Started with IAR.............................................................................................................35
The Microchip Website.................................................................................................................................38
– Board identification in Atmel Studio/Microchip MPLAB® X IDE
– One green power and status LED
– Programming and debugging
– Virtual serial port (CDC)
– Two debug GPIO channels (DGI GPIO)
• USB Powered
• Adjustable Target Voltage:
– MIC5353 LDO regulator controlled by the on-board debugger
– 1.8-5.5V output voltage (limited by USB input voltage)
– 500 mA maximum output current (limited by ambient temperature and output voltage)
ATtiny3217
Introduction
1.2 Kit Overview
The Microchip ATtiny3217 Curiosity Nano Evaluation Kit is a hardware platform to evaluate the ATtiny3217
microcontroller.
Steps to start exploring the ATtiny3217 Curiosity Nano Board:
1.Download Atmel Studio/Microchip MPLAB® X IDE.
2.Launch Atmel Studio/Microchip MPLAB® X IDE.
3.Optional: Use MPLAB® Code Configurator or Atmel START to generate drivers and examples.
4.Write your application code.
5.Connect a USB cable (Standard-A to Micro-B or Micro-AB) between the PC and the debug USB port on the
board.
Driver Installation
When the board is connected to your computer for the first time, the operating system will perform a driver software
installation. The driver file supports both 32- and 64-bit versions of Microsoft® Windows® XP, Windows Vista®,
Windows 7, Windows 8, and Windows 10. The drivers for the board are included with Atmel Studio/Microchip
MPLAB® X IDE.
Kit Window
Once the board is powered, the green status LED will be lit, and Atmel Studio/Microchip MPLAB® X IDE will autodetect which boards are connected. Atmel Studio/Microchip MPLAB® X IDE will present relevant information like data
sheets and board documentation. The ATtiny3217 device on the ATtiny3217 Curiosity Nano Board is programmed
and debugged by the on-board debugger and, therefore, no external programmer or debugger tool is required.
ATtiny3217
Getting Started
Tip: The Kit Window can be opened in MPLAB X IDE through the menu bar Window > Kit Window.
2.2 Design Documentation and Relevant Links
The following list contains links to the most relevant documents and software for the ATtiny3217 Curiosity Nano
Board:
• MPLAB® X IDE - MPLAB X IDE is a software program that runs on a PC (Windows®, Mac OS®, Linux®) to
develop applications for Microchip microcontrollers and digital signal controllers. It is called an Integrated
Development Environment (IDE) because it provides a single integrated “environment” to develop code for
embedded microcontrollers.
• Atmel Studio - Free IDE for the development of C/C++ and assembler code for microcontrollers.
• IAR Embedded Workbench® for AVR® - This is a commercial C/C++ compiler that is available for AVR
microcontrollers. There is a 30-day evaluation version as well as a 4 KB code-size-limited kick-start version
available from their website.
• MPLAB® Code Configurator - MPLAB Code Configurator (MCC) is a free software plug-in that provides a
graphical interface to configure peripherals and functions specific to your application.
• Atmel START - Atmel START is an online tool that helps the user to select and configure software components
and tailor your embedded application in a usable and optimized manner.
• Microchip Sample Store - Microchip sample store where you can order samples of devices.
• MPLAB Data Visualizer - MPLAB Data Visualizer is a program used for processing and visualizing data. The
Data Visualizer can receive data from various sources such as serial ports and on-board debugger’s Data
Gateway Interface, as found on Curiosity Nano and Xplained Pro boards.
• Studio Data Visualizer- Studio Data Visualizer is a program used for processing and visualizing data. The
Data Visualizer can receive data from various sources such as serial ports, on-board debugger’s Data Gateway
Interface as found on Curiosity Nano and Xplained Pro boards, and power data from the Power Debugger.
• Microchip PIC® and AVR Examples - Microchip PIC and AVR Device Examples is a collection of examples
and labs that use Microchip development boards to showcase the use of PIC and AVR device peripherals.
• Microchip PIC® and AVR Solutions - Microchip PIC and AVR Device Solutions contains complete applications
for use with Microchip development boards, ready to be adapted and extended.
• ATtiny3217 Curiosity Nano website - Kit information, latest user guide and design documentation.
• ATtiny3217 Curiosity Nano on Microchip Direct - Purchase this kit on Microchip Direct.
Curiosity Nano is an evaluation platform of small boards with access to most of the microcontrollers I/Os. The
platform consists of a series of low pin count microcontroller (MCU) boards with on-board debuggers, which are
integrated with Atmel Studio/Microchip MPLAB® X IDE. Each board is identified in the IDE. When plugged in, a Kit
Window is displayed with links to key documentation, including relevant user guides, application notes, data sheets,
and example code. Everything is easy to find. The on-board debugger features a virtual serial port (CDC) for serial
communication to a host PC and a Data Gateway Interface (DGI) with debug GPIO pin(s).
3.1 On-Board Debugger Overview
ATtiny3217 Curiosity Nano contains an on-board debugger for programming and debugging. The on-board debugger
is a composite USB device consisting of several interfaces:
• A debugger that can program and debug the ATtiny3217 in Atmel Studio/Microchip MPLAB® X IDE
• A mass storage device that allows drag-and-drop programming of the ATtiny3217
• A virtual serial port (CDC) that is connected to a Universal Asynchronous Receiver/Transmitter (UART) on the
ATtiny3217, and provides an easy way to communicate with the target application through terminal software
• A Data Gateway Interface (DGI) for code instrumentation with logic analyzer channels (debug GPIO) to visualize
program flow
The on-board debugger controls a Power and Status LED (marked PS) on the ATtiny3217 Curiosity Nano Board. The
table below shows how the LED is controlled in different operation modes.
Table 3-1. On-Board Debugger LED Control
ATtiny3217
Curiosity Nano
Operation ModePower and Status LED
Boot Loader modeThe LED blinks slowly during power-up.
Power-upThe LED is ON.
Normal operationThe LED is ON.
ProgrammingActivity indicator: The LED blinks slowly during programming/debugging.
Drag-and-drop
programming
FaultThe LED blinks rapidly if a power fault is detected.
Sleep/OffThe LED is OFF. The on-board debugger is either in a sleep mode or powered down.
3.1.1 Debugger
The on-board debugger on the ATtiny3217 Curiosity Nano Board appears as a Human Interface Device (HID) on the
host computer’s USB subsystem. The debugger supports full-featured programming and debugging of the
ATtiny3217 using Atmel Studio/Microchip MPLAB® X IDE, as well as some third-party IDEs.
Success:The LED blinks slowly for 2 sec.
Failure:The LED blinks rapidly for 2 sec.
This can occur if the board is externally powered.
Info: Slow blinking is approximately 1 Hz, and rapid blinking is approximately 5 Hz.
Remember: Keep the debugger’s firmware up-to-date. Firmware upgrades are done automatically when
Target MCU
UART TX
UART RX
Debugger
USB
CDC RX
CDC TX
PC
Terminal
Software
Target
Receive
Target
Send
Terminal
Receive
Terminal
Send
using Atmel Studio/Microchip MPLAB® X IDE.
3.1.2 Virtual Serial Port (CDC)
The virtual serial port (CDC) is a general purpose serial bridge between a host PC and a target device.
3.1.2.1 Overview
The on-board debugger implements a composite USB device that includes a standard Communications Device Class
(CDC) interface, which appears on the host as a virtual serial port. The CDC can be used to stream arbitrary data in
both directions between the host computer and the target: All characters sent through the virtual serial port on the
host computer will be transmitted as UART on the debugger’s CDC TX pin, and UART characters captured on the
debugger’s CDC RX pin will be returned to the host computer through the virtual serial port.
Figure 3-1. CDC Connection
ATtiny3217
Curiosity Nano
Info: As shown in Figure 3-1, the debugger’s CDC TX pin is connected to a UART RX pin on the target
for receiving characters from the host computer. Similarly, the debugger’s CDC RX pin is connected to a
UART TX pin on the target for transmitting characters to the host computer.
3.1.2.2 Operating System Support
On Windows machines, the CDC will enumerate as Curiosity Virtual COM Port and appear in the Ports section of the
Windows Device Manager. The COM port number can also be found there.
Info: On older Windows systems, a USB driver is required for CDC. This driver is included in installations
of Atmel Studio/Microchip MPLAB® X IDE.
On Linux machines, the CDC will enumerate and appear as /dev/ttyACM#.
Info: tty* devices belong to the “dialout” group in Linux, so it may be necessary to become a member of
that group to have permissions to access the CDC.
On MAC machines, the CDC will enumerate and appear as /dev/tty.usbmodem#. Depending on which terminal
program is used, it will appear in the available list of modems as usbmodem#.
Not all UART features are implemented in the on-board debugger CDC. The constraints are outlined here:
• Baud rate: Must be in the range of 1200 bps to 500 kbps. Any baud rate outside this range will be set to the
closest limit, without warning. Baud rate can be changed on-the-fly.
• Character format: Only 8-bit characters are supported.
• Parity: Can be odd, even, or none.
• Hardware flow control: Not supported.
• Stop bits: One or two bits are supported.
3.1.2.4 Signaling
During USB enumeration, the host OS will start both communication and data pipes of the CDC interface. At this
point, it is possible to set and read back the baud rate and other UART parameters of the CDC, but data sending and
receiving will not be enabled.
When a terminal connects on the host, it must assert the DTR signal. As this is a virtual control signal implemented
on the USB interface, it is not physically present on the board. Asserting the DTR signal from the host will indicate to
the on-board debugger that a CDC session is active. The debugger will then enable its level shifters (if available), and
start the CDC data send and receive mechanisms.
Deasserting the DTR signal will not disable the level shifters but disable the receiver so no further data will be
streamed to the host. Data packets that are already queued up for sending to the target will continue to be sent out,
but no further data will be accepted.
ATtiny3217
Curiosity Nano
Info: For all operating systems: Be sure to use a terminal emulator that supports DTR signaling. See
3.1.2.4 Signaling.
Remember: Set up the terminal emulator to assert the DTR signal. Without the signal, the on-board
debugger will not send or receive any data through its UART.
Tip: The on-board debugger’s CDC TX pin will not be driven until the CDC interface is enabled by the
host computer. Also, there are no external pull-up resistors on the CDC lines connecting the debugger and
the target, which means that during power-up, these lines are floating. To avoid any glitches resulting in
unpredictable behavior like framing errors, the target device should enable the internal pull-up resistor on
the pin connected to the debugger’s CDC TX pin.
3.1.2.5 Advanced Use
CDC Override Mode
In normal operation, the on-board debugger is a true UART bridge between the host and the device. However, in
certain use cases, the on-board debugger can override the basic operating mode and use the CDC TX and RX pins
for other purposes.
Dropping a text file into the on-board debugger’s mass storage drive can be used to send characters out of the
debugger’s CDC TX pin. The filename and extension are trivial, but the text file must start with the characters:
CMD:SEND_UART=
The maximum message length is 50 characters – all remaining data in the frame are ignored.
The default baud rate used in this mode is 9600 bps, but if the CDC is already active or has been configured, the
previously used baud rate still applies.
Sending data from the host to the CDC can be done byte-wise or in blocks, which will be chunked into 64-byte USB
frames. Each such frame will be queued up for sending to the debugger’s CDC TX pin. Transferring a small amount
of data per frame can be inefficient, particularly at low baud rates, because the on-board debugger buffers frames
and not bytes. A maximum of four 64-byte frames can be active at any time. The on-board debugger will throttle the
incoming frames accordingly. Sending full 64-byte frames containing data is the most efficient method.
When receiving data on the debugger’s CDC RX pin, the on-board debugger will queue up the incoming bytes into
64-byte frames, which are sent to the USB queue for transmission to the host when they are full. Incomplete frames
are also pushed to the USB queue at approximately 100 ms intervals, triggered by USB start-of-frame tokens. Up to
eight 64-byte frames can be active at any time.
If the host (or the software running on it) fails to receive data fast enough, an overrun will occur. When this happens,
the last-filled buffer frame will be recycled instead of being sent to the USB queue, and a full frame of data will be
lost. To prevent this occurrence, the user must ensure that the CDC data pipe is being read continuously, or the
incoming data rate must be reduced.
3.1.3 Mass Storage Device
The on-board debugger includes a simple Mass Storage Device implementation, which is accessible for read/write
operations via the host operating system to which it is connected.
It provides:
• Read access to basic text and HTML files for detailed kit information and support
• Write access for programming Intel® HEX formatted files into the target device’s memory
• Write access for simple text files for utility purposes
ATtiny3217
Curiosity Nano
3.1.3.1 Mass Storage Device Implementation
The on-board debugger implements a highly optimized variant of the FAT12 file system that has several limitations,
partly due to the nature of FAT12 itself and optimizations made to fulfill its purpose for its embedded application.
The Curiosity Nano USB Device is USB Chapter 9-compliant as a mass storage device but does not, in any way,
fulfill the expectations of a general purpose mass storage device. This behavior is intentional.
When using the Windows operating system, the on-board debugger enumerates as a Curiosity Nano USB Device
that can be found in the disk drives section of the device manager. The CURIOSITY drive appears in the file manager
and claims the next available drive letter in the system.
The CURIOSITY drive contains approximately one MB of free space. This does not reflect the size of the target
device’s Flash in any way. When programming an Intel® HEX file, the binary data are encoded in ASCII with
metadata providing a large overhead, so one MB is a trivially chosen value for disk size.
It is not possible to format the CURIOSITY drive. When programming a file to the target, the filename may appear in
the disk directory listing. This is merely the operating system’s view of the directory, which, in reality, has not been
updated. It is not possible to read out the file contents. Removing and replugging the board will return the file system
to its original state, but the target will still contain the application that has been previously programmed.
To erase the target device, copy a text file starting with “CMD:ERASE” onto the disk.
By default, the CURIOSITY drive contains several read-only files for generating icons as well as reporting status and
linking to further information:
• AUTORUN.ICO – icon file for the Microchip logo
• AUTORUN.INF – system file required for Windows Explorer to show the icon file
• KIT-INFO.HTM – redirect to the development board website
• KIT-INFO.TXT – a text file containing details about the board’s debugger firmware version, board name, USB
serial number, device, and drag-and-drop support
• STATUS.TXT – a text file containing the programming status of the board
Info: STATUS.TXT is dynamically updated by the on-board debugger. The contents may be cached by
the OS and, therefore, do not reflect the correct status.
3.1.3.2 Fuse Bytes
Fuse Bytes (AVR® MCU Targets)
When doing drag-and-drop programming, the debugger masks out fuse bits that attempt to disable Unified Program
and Debug Interface (UPDI). This means that the UPDI pin cannot be used in its reset or GPIO modes; selecting one
of the alternative functions on the UPDI pin would render the device inaccessible without using an external debugger
capable of high-voltage UPDI activation.
3.1.3.3 Limitations of Drag-and-Drop Programming
Lock Bits
Lock bits included in the hex file will be ignored when using drag-and-drop programming. To program lock bits, use
Atmel Studio/Microchip MPLAB® X IDE.
Enabling CRC Check in Fuses
It is not advisable to enable the CRC check in the target device’s fuses when using drag-and-drop programming. This
because a subsequent chip erase (which does not affect fuse bits) will effect a CRC mismatch, and the application
will fail to boot. To recover a target from this state, a chip erase must be done using Atmel Studio/Microchip MPLAB
X IDE, which will automatically clear the CRC fuses after erasing.
ATtiny3217
Curiosity Nano
®
3.1.3.4 Special Commands
Several utility commands are supported by copying text files to the mass storage disk. The filename or extension is
irrelevant – the command handler reacts to content only.
Table 3-2. Special File Commands
Command ContentDescription
CMD:ERASE
CMD:SEND_UART=
CMD:RESET
CMD:POWERTOGGLE
CMD:0V
CMD:3V3
CMD:5V0
Executes a chip erase of the target
Sends a string of characters to the CDC UART. See “CDC Override Mode”.
Resets the target device by entering Programming mode and then exiting
Programming mode immediately thereafter. Exact timing can vary according to
the programming interface of the target device. (Debugger firmware v1.16 or
newer.)
Powers down the target and restores power after a 100 ms delay. If external
power is provided, this has no effect. (Debugger firmware v1.16 or newer.)
Powers down the target device by disabling the target supply regulator. If
external power is provided, this has no effect. (Debugger firmware v1.16 or
newer.)
Sets the target voltage to 3.3V. If external power is provided, this has no effect.
(Debugger firmware v1.16 or newer.)
Sets the target voltage to 5.0V. If external power is provided, this has no effect.
(Debugger firmware v1.16 or newer.)
Info: The commands listed here are triggered by the content being sent to the mass storage emulated
disk, and no feedback is provided in the case of either success or failure.
3.1.4 Data Gateway Interface (DGI)
Data Gateway Interface (DGI) is a USB interface for transporting raw and timestamped data between on-board
debuggers and host computer-based visualization tools. MPLAB Data Visualizer is used on the host computer to
display debug GPIO data. It is available as a plug-in for MPLAB® X IDE or a stand-alone application that can be used
in parallel with Atmel Studio/Microchip MPLAB® X IDE.
Although DGI encompasses several physical data interfaces, the ATtiny3217 Curiosity Nano implementation includes
logic analyzer channels:
• Two debug GPIO channels (also known as DGI GPIO)
3.1.4.1 Debug GPIO
Debug GPIO channels are timestamped digital signal lines connecting the target application to a host computer
visualization application. They are typically used to plot the occurrence of low-frequency events on a time-axis – for
example, when certain application state transitions occur.
The figure below shows the monitoring of the digital state of a mechanical switch connected to a debug GPIO in
MPLAB Data Visualizer.
Figure 3-2. Monitoring Debug GPIO with MPLAB® Data Visualizer
ATtiny3217
Curiosity Nano
Debug GPIO channels are timestamped, so the resolution of DGI GPIO events is determined by the resolution of the
DGI timestamp module.
3.1.4.2 Timestamping
DGI sources are timestamped as they are captured by the debugger. The timestamp counter implemented in the
Curiosity Nano debugger increments at 2 MHz frequency, providing a timestamp resolution of a half microsecond.
Important: Although bursts of higher-frequency signals can be captured, the useful frequency range of
signals for which debug GPIO can be used is up to about 2 kHz. Attempting to capture signals above this
frequency will result in data saturation and overflow, which may cause the DGI session to be aborted.
User Guide
DS40002193A-page 12
Loading...
+ 28 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.