Microchip Technology EV76S68A User Manual Download Page 6

Page: 6 / 22

•

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.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 that is implemented on the USB interface but not in the hardware on the debugger. Asserting a 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. Disserting 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

In 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 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 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 divided 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, since the debugger buffers per frame, not byte. 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 the 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.2

Curiosity Nano Standard Pinout

The twelve edge connections closest to the USB connector on the Curiosity Nano kits have a standardized pinout.
The program/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

No connect.

ID line for extensions.

CDC RX

UART TX

USB CDC RX line.

CDC TX

UART RX

USB CDC TX line.