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 will disable the receiver, therefore 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: 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 CDC TX pin of the on-board debugger 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, such as framing errors, the target device must enable the internal
pull-up resistor on the pin connected to the CDC TX pin of the debugger.
4.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 mass storage drive of the on-board debugger can be used to send characters out of the
CDC TX pin on the debugger. The file name 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 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
previously 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 such frame will be queued up for sending to the CDC TX pin of the debugger. Transferring a small
amount of data per frame can be inefficient, particularly at low-baud rates, as 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 CDC RX pin of the debugger, 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.
4.1.3 Mass Storage Device
The on-board debugger includes a simple mass storage device implementation, which is accessible for read/write
operations through the Host operating system to which it is connected.
The mass storage device provides the following:
• Read access to basic text and HTML files for detailed kit information and support.
SAM-IoT Wx v2
Hardware User Guide
© 2022 Microchip Technology Inc.
and its subsidiaries
User Guide DS70005506A-page 10
