USB CDC Echo problem

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello, 

 

Perhaps someone can point me in the right direction. 

I have downloaded the USB CDC echo example through Atmel START for the SAME70 Xplained board and programmed it.

The virtual COM port does show up in Windows (version 10 Pro) but as soon as I want to open the port in a terminal program (Realterm v. 2.0.0.70) I get an error "The parameter is incorrect".

 

(In a similar way I tried the USB MSC example and that seems to work ok.)

 

In addition I loaded the ASF3 Device CDC example and that works as expected. (Conclusion: hardware is ok.)

 

Does anyone have an idea what I am doing wrong?

Thanks!

 

 (SAME70_DFP 2.4.166 (2019-02-18); CMSIS 5.4.0 (2018-08-01); AS 7.0.2397)

 

This topic has a solution.
Last Edited: Thu. Jul 16, 2020 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

maartend wrote:
I get an error "The parameter is incorrect".

Where do you get that - in RealTerm ?

 

Have you tried any other terminals?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the error message was reported by Realterm. 

I did try another terminal program (company own) that reported something like "no port" (although it showed up in that programs "select serial port dialog").

I also tried the same procedure on another Windows (10) PC with the same results.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Thanks, looks like something goes wrong when setting baud rate. 

 

 

 

Weird because these setting play no role in USB communication... 

(Still no clue if it is a Windows problem or firmware. I guess on Windows as I can expect an example of 2015~2018 should be ok, right?)

Need to dig deeper in the matter! 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update: 

When monitoring on Serial Port Monitor program switched to off --> then reset the Xplained board --> Start monitoring --> Open the port (with Serial Port Monitor (SPM) program) : it works. I can send and receive bytes (from within SPM).

Then close the COM port and try to open again I get "STATUS_INVALID_PARAMETER when SPM is trying to SET the baud rate.

The firmware is still responsive. 

 

When monitoring and starting Realterm, it seems that when opening the COM port (from Realterm)  the iniatialisation is done twice, first time ok (set baud rate,  and all other settings (set RTS, clear DTR, set line control, set CHARS, set HANDFLOW). Then it starts over by setting and getting all the parameters. When trying to set the baud rate it fails with the invalid parameter error.

Looks like it is a firmware issue...

 

(The procedure for opening a COM port with SPM and Realterm are not exactly the same, Realterm does do much more getting and setting and in a different order.)

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update 2:

Finally I decided to try to find a PC with another OS than Windows 10 and I found an old laptop with Windows 7. After installing the (unsigned) Atmel drivers and opening Realterm all seems to be working ok. 

I can send and receive bytes and opening and closing the COM port (in Realterm) without any problem.

Is this really a Windows 10 (driver) issue? 

If yes, how to explain the correct functioning of the ASF3 CDC example (although it is an UART-USB bridge function so it is not 1:1 comparable perhaps)?

 

Hope someone can enlighten me!

Thanks

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

maartend wrote:
Is this really a Windows 10 (driver) issue? 

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

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil,

Thanks again for your reply.

 

The problem is that "my" firmware is made by the people from Atmel/Microchip.

My intention was a good base from which to build up my application. So far the ASF3 example seems a more reliable way to start. But it was last updated in 2019...

(The future of ASF4 is perhaps also uncertain as Microchip seems to want to push MPLAB / Harmony...)

 

My knowledge of the USB protocol is very basic, so making my own CDC ACM layer is somewhat of a challenge.

 

Perhaps switching to MPLABX and harmony will be the way to go. Unfortunately no USB CDC harmony example for the SAME70 Xplained board.

 

 

(Perhaps going back to the other chip vendor is more future proof?!)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

maartend wrote:
The problem is that "my" firmware is made by the people from Atmel/Microchip.[/quote

maybe raise a support ticket, then

 

https://community.atmel.com/comm...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just did, hoping for quick response :-) 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

 

 

Geoff S.

Lead Embedded Software Developer

Co-Owner, Motus Design Group

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seeing the same thing.  When connecting a Win 10 machine to a SAME70 device via USB, the first connection is successful.  But if the PC side program is closed then reopened, or if the USB cable is disconnected then reconnected, the SAME70 device will no longer communicate to the Windows PC.  But power cycling the SAME70 device makes it work again.  There have been no changes to the SAME70 device in over a year, nor the PC side program (TeraTerm).  But Win 10 was updated in the past month or so.

 

I think I've narrowed it down to a Windows 10 driver problem in usbser.sys.  With Win 10 1903 (build 18362) released May 21, 2019 everything functions fine.  The usbser.sys driver provided by Microsoft is marked 10.8.18362.1.  But with Windows 10 2004 (build 19041) released on May 27, 2020 it fails.  The usbser.sys driver provided by Microsoft is marked 10.8.19041.1.  A closer look at each file shows the older one as 79,360 bytes and the newer one as 81,920 bytes.  So something changed in the Microsoft supplied default USB CDC driver that broke the Atmel side SAME70 usb driver.  I'm using the latest ASF4/START usb cdc driver from Atmel.

I'm stuck trying to install the build 18362 driver on the build 19041 machine as Windows is complaining about lack of driver signing.  I really don't want to write a custom Win 10 driver to solve this one.

 

Go to a command prompt in Windows and type 'ver' to see the actual version install on your PC.  Do you have Microsoft Windows [Version 10.0.19041.450] running too?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@maartend - Can you post your bug info so I can track it too?  I'm interest to see how responsive (or unresponsive) Atmel is.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am not sure what you mean by my "bug info". I just checked my support ticket state concerning this issue: "in progress".

Last comment was : "try using another terminal program..." This was around 16th of July...

(I did have a holiday during September. The project is now using communication by UART and separate USB serial bridge. Of course this is cannot be used in finale solution but for developing and testing other parts of the firmware it is ok.)

 

Maarten