Microchip Technology PIC16F18076 User Manual Download

Page: 11 / 41

Not all UART receivers have support for detecting a break, but a correctly-formed break character usually triggers a
framing error on the receiver.

Sending a break character using the debugger's CDC has the following limitations:

• Sending a break must NOT be done at the same time as using the CDC Override mode (drag-and-drop). Both

these functions are temporary states, so they must be used independently.

• Sending a break will cause data currently being sent to be lost. Be sure to wait a sufficient amount of time to

allow all characters in the transmission buffer to be sent (see above section) before sending the break. This is
also in line with expected break character usage: For example, reset a receiver state-machine after a timeout
occurs waiting for data to be returned to the host.

• The CDC specification allows for debugger-timed breaks of up to 65534ms in duration to be requested. For

simplicity, the debugger will limit the break duration to a maximum of 11 bit-durations at its minimum supported
baud rate.

• The CDC specification allows for indefinite host-timed breaks. It is the responsibility of the terminal application/

user to release the break state in this case.

Note:

Sending break characters is available in debugger firmware version 1.24 and later.

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

3.1.3.1

Mass Storage Device Implementation

The on-board debugger implements a highly optimized variant of the FAT12 file system having 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
found in the disk drives section of the device manager. The CURIOSITY drive appears in the file manager and claims
the following available drive letter in the system.

The CURIOSITY drive contains approximately one MB of free space and does not reflect the target device’s Flash
size. When programming an Intel

HEX file, the binary data are encoded in ASCII with metadata providing a large

overhead, so 1 MB is a trivially chosen value for disk size.

It is not possible to format the CURIOSITY drive. The filename may appear in the disk directory listing when
programming a file to the target, which is merely the operating system’s view of the directory that, 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 previously programmed application.

Copy a text file starting with “

CMD:ERASE

” onto the disk to erase the target device.

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