AVR Freaks

I have used this before to see what's happening with serial ports:

https://www.eltima.com/products/serial-port-monitor/

It lists all the windows system events going on - that may give you better information ?

The 30-day free trial should be sufficient ...

It could be that there is some "issue" with your firmware which you just happen to get away with on Win 7, but Win 10 objects to. Especially when you add-in USB3

See also:   https://www.avrfreaks.net/forum/xmega-lufa-and-usb-30-problem

Facing the exact same problem.

Putty works fine on first try. Restarting the putty session will fail the connection.

Connection with python serial works as well.

Connection with YAT, RealTerm, uCon, Termite all have the same problem as above.

Our primary use case is python, but it would be nice to be able to debug with a raw serial terminal such as RealTerm, and get proper stability.
I have an older project that used the CDC implementation on ASF3 which did not have this problem. I moved to ASF4 as the Atmel Studio ASF Wizard breaks if you have python 3 installed. ASF4 CDC uses DMA, while ASF3 is heavily interrupt based transfers. Our ASF3 project was also a CDC + HID composite device.

Here is a git repo of the example https://github.com/gshera/E70_CDC modified very slightly from the example.

I've change the cdcd_acm_example() to output 1234567890 every few seconds and do loop back of input characters.

Correspondence with microchip support has been as follows:

Please enable RTS and DTR(data terminal ready) on your terminal application(s) before transfer. We have seen that Putty does it by default and hence it works.

and

If you want to disable flow control in the firmware, you can stream the data directly instead of waiting for a line state change.

You can register the read and write callbacks in this function similar to usb_device_cb_state_c

I've added these at //microchip sections

void cdcd_acm_example(void)

{

while (!cdcdf_acm_is_enabled()) {

// wait cdc acm to be installed

};

NVIC_SetPriority(USBHS_IRQn, 4); //MOTUS, do not exceed RTOS max, atmel smart default is 0

cdcdf_acm_register_callback(CDCDF_ACM_CB_STATE_C, (FUNC_PTR)usb_device_cb_state_c);

cdcdf_acm_register_callback(CDCDF_ACM_CB_READ, (FUNC_PTR)usb_device_cb_bulk_out);

cdcdf_acm_register_callback(CDCDF_ACM_CB_WRITE, (FUNC_PTR)usb_device_cb_bulk_in);

This does not help as you still can not connect if the flow settings are not some perfect match or reconnect. 

It seems like there is a problem more associated with reconnection than with flow control.

I have confirmed the problem is with START/ASF4 and Windows 10 version 2004.  Using just the SAME70 Xplained board powered externally and CDC sample programs from Atmel, here are my results:

1. SAME70 XPlained board with START/ASF4 demo code, Win 10 version 1909 – SUCCESS - USB connects, disconnects, and reconnects as expected
2. SAME70 XPlained board with ASF3 demo code, Win 10 version 1909 – SUCCESS
3. SAME70 XPlained board with START/ASF4 demo code, Win 10 version 2004 – FAILS - USB will only connect once.  If the connection or cable disconnected then reinserted, communcation halts.  The SAME70 Xplained board must be power cycled to restore communications.
4. SAME70 XPlained board with ASF3 demo code, Win 10 version 2004 – SUCCESS!!

So ASF3 works with all released Win 10 versions but ASF4 fails with only the latest Win 10 version.  I'm thinking there is a problem with resetting the USB driver after a state change on the USB bus.  The only way to recover is to power cycle the hardware.  More work to do here including filing a bug report with Atmel.