topic MK66 communication issue with virtual COM port via USB in Kinetis Microcontrollers

MK66 communication issue with virtual COM port via USB

vyacheslavguzhv — Wed, 23 Oct 2019 12:45:34 GMT

hi colleagues,

need your support please! The communication issue happens with simple setup.

MK66 works as slave and is connected to Linux (Ubuntu or Astra) WS. The MK66 executes "echo" application. I.e. it returns back the data received.

Running following repeating sequence on the WS gives communication error:

Call open.
Call write (9 bytes transfer via COM).
read (9 bytes reception from COM).
Call close.

this gives the communication error once per 1000 cycles.

It worth to remark that:

1) disabling the modem lines (CLOCAL) on the WS side helps to avoid the issue.

But unfortunately according to the existing setup specific, the host side cannot be changed/updated.

2) In case we remove Open/Close from the loop, the issue disappears. But again this is already existing protocol, which we cannot modify unfortunately.

3) USB cable is shielded

4) using Windows based WS reduce number or communication errors due to Windows USB driver specific, which tries to recover automatically.

Kindly help to find the workaround on the MK66 side.

thanks!

Slava

Re: MK66 communication issue with virtual COM port via USB

Alexis_A — Wed, 23 Oct 2019 19:44:37 GMT

Hi Vyacheslav,

A rapid workaround I could suggest is to try to resent the same package when this fails and if the USB interface is getting stuck reinitialize the interface.

Also could you identify the reason the code is getting after all the iterations? Is the memory buffer full? Or did you identify the error status?

Best Regards,

Alexis Andalon

Re: MK66 communication issue with virtual COM port via USB

vyacheslavguzhv — Thu, 24 Oct 2019 09:11:39 GMT

Hi Alexis,

Thanks for the answer and great support!

The tricky point is that we integrate the device into existing infrastructure,

where the COM-host devices are released in the field and cannot be changed. In

fact they work fine with other COM slaves from other suppliers.

Therefore the only acceptable solution unfortunately is the COM-slave

modification (MK66 based).

The error can happen on write or read operations in any time. The code 0 (EOF)

is returned, the errno = (EIO 5 Input/output error).

The I/O buffers may remain empty, i.e. the error can happen during the first

byte transmission.

Thanks!

Slava

Re: MK66 communication issue with virtual COM port via USB

Alexis_A — Thu, 24 Oct 2019 19:44:33 GMT

Hi Vyacheslav,

I think this is related to the errate mentioned in the following document:

https://www.nxp.com/docs/en/errata/KINETIS_K_0N65N.pdf

This document also mention a workaround for this problem.

Let me know if this helps you.

Best Regards,

Alexis Andalon

Re: MK66 communication issue with virtual COM port via USB

vyacheslavguzhv — Fri, 25 Oct 2019 15:15:27 GMT

Hi Alexis!

Thanks!

In case you mean the error “e8807” i think its not our case. As the USB works in HS mode, as the slave and clocked from external clock (12mHz) multiplied by 40 and connected to USBPHYPLLCLK.

Kindly suggest if this is the case you mean?

Thanks!

Slava

Re: MK66 communication issue with virtual COM port via USB

Alexis_A — Fri, 25 Oct 2019 17:28:33 GMT

Hi Vyacheslav,

Sorry for not clarifying, I mean the e7919.

Best Regards,

Alexis Andalon

Re: MK66 communication issue with virtual COM port via USB

vyacheslavguzhv — Mon, 28 Oct 2019 08:01:43 GMT

Hi Alexis,

Thanks!

The e7919 is about USBx_SOFTHLD. The SOF Threshold Register is used only in

Host mode (HOSTMODEEN=1).

In our case the device is not host.

Thanks!

Slava

Re: MK66 communication issue with virtual COM port via USB

vyacheslavguzhv — Tue, 29 Oct 2019 15:14:58 GMT

Hi Alexis,

Kindly find attached the sample to reproduce the issue and the Linux client to work together.

Customer uses RTSO, but even w/o it the issue is there.

Thanks!

Slava

Re: MK66 communication issue with virtual COM port via USB

mjbcswitzerland — Tue, 29 Oct 2019 22:43:46 GMT

In case you don't find a solution take a look at the uTasker USB-CDC support for K66 HS and FS interfaces. The project is available as free open source or professionally supported and its quality CDC implementation ensures performance, efficiency and robustness as proven in many industrial products.

Regards

Mark

Complete Kinetis solutions for faster/more efficient professional needs, training and support: http://www.utasker.com/kinetis.html
i.MX RT project compatibility: http://www.utasker.com/iMX.html
Including FreeRTOS integration for all Kinetis parts

Kinetis K66:
- http://www.utasker.com/kinetis/TWR-K65F180M.html
- http://www.utasker.com/kinetis/FRDM-K66F.html
- http://www.utasker.com/kinetis/TEENSY_3.6.html

USB-CDC Host/device connection video: https://www.youtube.com/watch?v=XhISV1czIo4&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=16

uTasker: supporting >1'000 registered Kinetis users get products faster and cheaper to market

Request Free emergency remote desk-top consulting at http://www.utasker.com/services.html

Open Source version at https://github.com/uTasker/uTasker-Kinetis

https://community.nxp.com/thread/512558
https://community.nxp.com/thread/352862
https://community.nxp.com/thread/498809

Re: MK66 communication issue with virtual COM port via USB

Alexis_A — Thu, 31 Oct 2019 01:53:43 GMT

Dear Vyacheslav,

Testing your code what I could see is that sometimes when a package is send it from the CPU, the content is not the same size and the content is different from the one is sent and your code doesn't handle transmission that are less than 9 bytes so if there's a problem with the communication the device is not put to receive anymore. Adding this to handle receptions less than 9 bytes resolve the stuck problem. Could you let me know if this behavior is like the one your seeing in your side?

Best Regards,

Alexis Andalon

Re: MK66 communication issue with virtual COM port via USB

vyacheslavguzhv — Thu, 31 Oct 2019 08:08:51 GMT

Hi Alexis!

The issue you observe is not really the one which we mean. The one you see is managed by the customer already.

First of all kindly find attached the source of Linux application this would help to reproduce the issue.

In details the flow related to the issue is follows:

1. Open() call for virtual COM

2. Write() call doesn’t produce any errors

3. Read() returns immediately with zero bytes received and errNo=0. Read() call is the synchronous which means it returns only in case the error happens or in case some data is received. As there is no real data, logically such behavior means EOF. I.e. the virtual COM was closed right after Write() execution.

From MK66 side the data sent on step 1 is received, handled and the response is sent back to PC. The PC didn’t call Close(). But MK66 has received the Set Control Line State request and has changed the state startTransactions=0 (was equal to 1).

Thanks!

Slava

Re: MK66 communication issue with virtual COM port via USB

vyacheslavguzhv — Thu, 31 Oct 2019 09:10:39 GMT

Alexis,

This is the fix to avoid the issue you face. Just replace your “virtual_com.c” with the attached file.

Thanks!

Slava

Re: MK66 communication issue with virtual COM port via USB

vyacheslavguzhv — Thu, 31 Oct 2019 09:31:03 GMT

Alexis,

Kindly find below some supplementary remarks about the issue:

1. The issue raises once per 100-1000 open-write-read-close cycles using sample application shared previously.

2. In case of issue supplementary calls of Read() and Write() also return error. To recover need to call close() + open().

3. In case we introduce 10ms delay between open() and write(), than write() returns error instead of read().

4. In case modem lines are disabled on PC the issue disappears.

Thanks!!

Slava

Re: MK66 communication issue with virtual COM port via USB

vyacheslavguzhv — Thu, 31 Oct 2019 09:51:27 GMT

Please use this Virtual_com.c

Re: MK66 communication issue with virtual COM port via USB

Alexis_A — Thu, 30 Jan 2020 23:30:38 GMT

Hello vyacheslavguzhva‌,

Sorry for the late replay, I receive an answer from the applications team and looks like this error is related to the one in the following post and adding the flag helps to not get stuck:

static bool received_data = TRUE;  ‍

Unfortunately adding this shows the same symptoms as a Windows WS (intermittently returns error). The applications team still looking into it.

Best Regards,

Alexis Andalon