The PIC18F47K42 Curiosity Nano Evaluation Kit is a hardware platform to evaluate the PIC18F47K42
microcontroller.
Supported by Microchip MPLAB® X Integrated Development Environment (IDE), the kit provides easy
access to the features of the PIC18F47K42 to explore how to integrate the device into a custom design.
The Curiosity Nano series of evaluation kits include an on-board debugger. No external tools are
necessary to program and debug the PIC18F47K42.
Steps to start exploring the Curiosity Nano platform:
1.Download Microchip MPLAB® X.
2.Launch Microchip MPLAB® X.
3.Connect a USB cable (Standard-A to Micro-B or Micro-AB) between the PC and the debug USB
port on the kit.
When the Curiosity Nano kit 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 kit are
included with Microchip MPLAB® X.
Once the Curiosity Nano board is powered the green status LED will be lit and Microchip MPLAB® X will
auto-detect which Curiosity Nano board is connected. Microchip MPLAB® X will present relevant
information like data sheets and kit documentation. The PIC18F47K42 device is programmed and
debugged by the on-board debugger and therefore no external programmer or debugger tool is required.
PIC18F47K42 Curiosity Nano
Getting Started
®
2.2 Design Documentation and Relevant Links
The following list contains links to the most relevant documents and software for the PIC18F47K42
Curiosity Nano.
• 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.
• 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.
• Microchip Sample Store - Microchip sample store where you can order samples of devices.
• Data Visualizer - Data Visualizer is a program used for processing and visualizing data. The Data
Visualizer can receive data from various sources such as the EDBG Data Gateway Interface found
on Curiosity Nano and Xplained Pro boards and COM Ports.
• PIC18F47K42 Curiosity Nano website - Kit information, latest user guide and design
documentation.
• PIC18F47K42 Curiosity Nano on microchipDIRECT - Purchase this kit on microchipDIRECT.
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 Microchip MPLAB® X. Each board is identified in the IDE, and relevant user
guides, application notes, data sheets, and example code are easy to find. The on-board debugger
features a Virtual COM port (CDC) for serial communication to a host PC, and a Data Gateway Interface
(DGI) GPIO logic analyzer pin.
3.1 On-board Debugger
The PIC18F47K42 Curiosity Nano contains an on-board debugger for programming and debugging. The
on-board debugger is a composite USB device of several interfaces: A debugger, a mass storage device,
a data gateway, and a Virtual COM port (CDC).
Together with Microchip MPLAB® X, the on-board debugger can program and debug the PIC18F47K42.
A Data Gateway Interface (DGI) is available for use with the logic analyzer channels for code
instrumentation, to visualize the program flow. DGI GPIOs can be graphed using the Data Visualizer.
PIC18F47K42 Curiosity Nano
Curiosity Nano
The Virtual COM port is connected to a UART on the PIC18F47K42 and provides an easy way to
communicate with the target application through terminal software.
The on-board debugger controls a Power and Status LED (marked PS) on the PIC18F47K42 Curiosity
Nano. The table below shows how the LED is controlled in different operation modes.
Table 3-1. On-Board Debugger LED Control
Operation ModeStatus LED
Boot Loader modeLED blink at 1 Hz during power-up.
Power-upLED is ON.
Normal operationLED is ON.
ProgrammingActivity indicator: The LED flashes slowly during programming/debugging.
FaultThe LED flashes fast if a power fault is detected.
Sleep/OffLED is off. The on-board debugger is either in Sleep mode or powered down.
3.1.1 Virtual COM Port
The Virtual COM Port is a general purpose serial bridge between a host PC and a target device.
3.1.1.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 COM Port. The CDC can be used
to stream arbitrary data in both directions between the host and the target: All characters sent from the
host will be sent through a UART on the CDC TX pin, and UART characters sent into the CDC RX pin will
be sent back to the host through the Virtual COM Port.
This can occur if the kit is externally powered.
On Windows machines, the CDC will enumerate as Curiosity Virtual COM Port and appear in the Ports
section of the device manager. The COM port number is shown here.
On Linux machines, the CDC will enumerate and appear as /dev/ttyACM#.
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#.
3.1.1.2 Limitations
Not all UART features are implemented in the on-board debugger CDC. The constraints are outlined
here:
• Baud rate must be in the range 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.
PIC18F47K42 Curiosity Nano
Curiosity Nano
Info: On older Windows systems, a USB driver is required for CDC. This driver is included in
MPLAB X and Atmel® Studio installations.
3.1.1.3 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. This is a virtual control signal
implemented on the USB interface, but not in hardware in the on-board debugger. Asserting DTR from
the host will indicate to the on-board debugger that a CDC session is active, will 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.
Remember: Enable to set up your terminal emulator to assert the DTR signal. Without it, the
on-board debugger will not send or receive any data through its UART.
3.1.1.4 Advanced Use
CDC Override Mode
In normal operation, the on-board debugger is a true UART bridge between the host and the device.
However, under certain use cases, the on-board debugger can override the basic operating mode and
use the CDC pins for other purposes.
Dropping a text file (with extension .txt) into the on-board debugger’s mass storage drive can be used
to send characters out of the CDC TX pin. 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 baud rate last used still applies.
USB-Level Framing Considerations
Sending data from the host to the CDC can be done byte-wise or in blocks, which will be chunked into 64byte USB frames. Each such frame will be queued up for sending to the CDC TX pin. Transferring a small
amount of data per frame can be inefficient, particularly at low baud rates, since the on-board debugger
buffers frames and not bytes. A maximum of 4 x 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.
When receiving data from the target, the on-board debugger will queue up the incoming bytes into 64byte 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-offrame tokens. Up to 8 x 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.2 Mass Storage Disk
A simple way to program the target device is through drag and drop with .hex files.
3.1.2.1 Mass Storage Device
The on-board debugger implements a highly optimized variant of the FAT12 file system that has a number
of limitations, partly due to the nature of FAT12 itself and optimizations made to fulfill its purpose for its
embedded application.
The CURIOSITY drive 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.
The on-board debugger enumerates as a Curiosity Nano USB device that can be found in the disk drives
section of the Windows 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 a .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
kit 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 kit firmware, name, serial number, and
device.
• 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 not reflect the correct status.
3.1.2.2 Configuration Words
Configuration Words (PIC® MCU Targets)
Configuration Word settings included in the project being programmed after program Flash is
programmed. The debugger will not mask out any bits in the Configuration Words when writing them, but
since it uses Low-Voltage Programming mode, it is unable to clear the LVP Configuration bit. If the
incorrect clock source is selected, for example, and the board does not boot, it is always possible to
perform a bulk erase (always done before programming) and restore the device to its default settings.
PIC18F47K42 Curiosity Nano
Curiosity Nano
3.2 Curiosity Nano Standard Pinout
The twelve edge connections closest to the USB connector on Curiosity Nano kits have a standardized
pinout. The program/debug pins have different functions depending on the target programming interface
as shown in the table and figure below.