• Stop bits: One or two bits are supported.
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 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 that is implemented on the USB interface but not in hardware on the debugger. Asserting DTR from the host
will indicate to the debugger that a CDC session is active, and it 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 it will
disable the receiver, hence 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.
3.1.1.4
Advanced Use
When the CDC Override mode is in normal operation, the On-Board Nano Debugger is a true UART bridge between
the host and the device. However, under certain use cases, the debugger can override the Basic Operating mode
and use the CDC pins for other purposes. Dropping a text file (with extension
.txt
) into the 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, and all remaining data in the frame is ignored.
The default baud rate used in this mode is 9600 bps, but if the CDC is already active or has been configured, the
recently used baud rate 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 64-byte USB
frames. Each frame will be queued up for sending to the CDC TX pin. Sending a small amount of data per frame can
be inefficient, particularly at low-baud rates, because the debugger buffers frames, not bytes. A maximum of 4 x 64-
byte frames can be active at any time, the 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 debugger will queue up
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 8 x 64-byte frames can be active at any time. If the host or 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.
Note:
Mass storage disk is not supported during this release.
3.1.2
Mass Storage Disk
Not supported at this time.
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 and debug pins have different functions depending on the target programming interface as shown in the
following table and figure.
Table 3-2. Curiosity Nano Standard Pinout
Debugger Signal
ICSP Target
Description
NC
-
No connect.
ID
-
ID line for extensions.
CDC RX
UART TX
USB CDC RX line.
CDC TX
UART RX
USB CDC TX line.
DBG1
SWCLK
Debug clock line
DBG2
GPIO
DGI GPIO
SAM D21
Curiosity Nano
©
2020 Microchip Technology Inc.
User Guide
DS70005409C-page 6
Downloaded from
Downloaded from
Downloaded from
Downloaded from
Downloaded from
Downloaded from
