K22 + MCUxpesso and CDC Virtual COM Port example

[balbet]

Hi,

We have a problem with the example imported with the SDK (version 2.8.2) with MCUxpresso when using a MK22FN512xxx12. The imported example is called "dev_cdc_vcom_bm", and it works fine: you can open the serial port, and everything you write, it echoes the characters back. The problem comes when in the APPTask() you comment this line:

if (s_sendSize)
{
uint32_t size = s_sendSize;
s_sendSize = 0;

//error = USB_DeviceCdcAcmSend(s_cdcVcom.cdcAcmHandle, USB_CDC_VCOM_BULK_IN_ENDPOINT, s_currSendBuf, size);

if (error != kStatus_USB_Success)
{
/* Failure to send Data Handling code here */
}
}

In other words, we want to receive characters without sending anything back. When this happens, the serial port just hangs, as well as the USB peripheral (doesn't generate any more IRQs).

Another thing which seems weird to us is that when we send some data, the IRQ calls the event "kUSB_DeviceCdcEventSendResponse", where it's called the "USB_DeviceCdcAcmRecv" function. Why the Tx and Rx are dependent? We've seen other stacks where you can receive and send data regardless of each other, at the end, we try to emulate a UART, right?

Can anyone else reproduce this issue or has any clues on how to solve it?

Thanks!

[ErichStyger]

Hi @balbet ,

The examples are just that: showing a basic use case. I did had to modify the provided example as well a bit to make it work  for other/real cases. Have a look at what @mjbcswitzerland provided. Or have a look how I tweaked the implementation (using a ring buffer to decouple send/receive properly). Have a look at the virtual_com.c (added my comments in there) which is on https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/MCUXpresso/tinyK22/tinyK22_Raspberr...

One thing to mention is that you need to serve the 'AppTask' frequently (say every 10 or 20 ms depending on your buffers/speed).

I hope this helps,

Erich

[balbet]

Ups sorry, I replied the other response and didn't see yours. Great, we'll take a look at this new code, let's see if it works.

Thank you very much!

[mjbcswitzerland]

Hi

If you search the forum your will find this topic discussed where the issue is confirmed and a workaround suggested.

For fully reliable and industrial proven USB-CDC with robust and fully flexible interface (for for all Kinetis parts with USB and also USB simulation) you can use the free Open Source uTasker project https://github.com/uTasker/uTasker-Kinetis

It is also available as professionally supported version for mission critical work and you can verify USB reliability and performance with the following K22 binaries (including multiple CDC and CDC-UART bridges):
https://www.utasker.com/kinetis/FRDM-K22F.html
https://www.utasker.com/kinetis/TWR-K22F120M.html
https://www.utasker.com/kinetis/BLAZE_K22.html
https://www.utasker.com/kinetis/tinyK22.html

See USB-CDC host to device on Kinetis at https://www.youtube.com/watch?v=XhISV1czIo4&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q&index=16

Other references:
USB demo and simulation : https://www.utasker.com/docs/uTasker/uTaskerV1.3_USB_Demo.PDF
USB user's guide: https://www.utasker.com/docs/uTasker/USB_User_Guide.PDF

uTasker Kinetis projects can work also on i.MX RT parts with almost no porting effort when more performance and multiple USBs are required in follow-on projects.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key

[balbet]

Hi Mark,

Thanks for your ultra fast response   It would be nice to use uTasker, but the thing is we are stuck with MQX, since we have a lot of code already written using it. So, what we did was to generate the example with MCUxpresso (the PE with KDS doesn't have any example of a virtual COM port), and we adapted the code to work with MQX.

Now our code works the same way in KDS+MQX as it does in MCUxpresso. So, can you please link to the forum where you say this issue was discussed with a workaround? Sorry, I couldn't find it

Thank you very much,

[mjbcswitzerland]

Hi

I am sorry but I also don't find the post anymore but I remember (around 6 weeks ago) testing the examples and confirming that if nothing is sent back the USB stack is left in a state where it can't receive anything else. The poster seemed to settle for a workaround of sending dummy data but I don't remember the details.
As Eric states the examples are examples - starting points to get going but not necessarily proven for productive work. Also the USB stack changes with time so there is no backward compatibility between versions.

I use the uTasker USB stack with FreeRTOS since one can simply put the complete project into a task and the same can be done with MQX, CMX, etc.
The open source version also includes FreeRTOS operation with the uTasker USB stack by enabling the define FREE_RTOS_USB. This also enables easy use of various uTasker packages, such as Modbus, or advanced drivers (such as the DMA UART capabilities with free-running DMA UART reception or DMX) with almost any OS without complications. Code is IAR, Keil, GCC, KDS, MCUXpresso, Greenhills compatible and can work alongside of other libraries or parts of project that have already been developed.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key

[ErichStyger]

Hi @balbet ,

>>(the PE with KDS doesn't have any example of a virtual COM port)

I do use Processor Expert for USB CDC too, see https://mcuoneclipse.com/2014/12/27/usb-with-the-freescale-frdm-k22f-board/

Basically this is a Processor Expert wrapper for the Freescale USB stack. If you want to go down that route, the components are available on https://sourceforge.net/projects/mcuoneclipse/files/PEx%20Components/

I hope this helps,

Erich

[balbet]

Great Erich!

It seems the perfect solution for us, we will try. Can you confirm if this solution you propose also works with MQX? A workmate had some issues with the fsl_debug_console (which is required for the USB component) when we tried to integrate the USB with MQX, basically because we use NIO.

Thanks,

[myke_predko]

@balbet 

I had issues with USB CDC & HID with MQX when I was working with it 5+ years ago.  I ended up hiring HCC-Embedded to do it for us.  

IIRC, MQX doesn't play nicely with the timers (or at least not as nicely as FreeRTOS does) and they way they're allocated/used (I think they're used without recording an allocation in the OS which means you have to go into MQX's guts to figure out what is actually going on and this) causes problems with how the USB operates.  

Personally, I'd recommend porting from MQX to FreeRTOS, messaging works a bit differently (ie execution doesn't automatically do a task scan after to you put a message on somebody's stack) but it's very stable, I think a bit faster for task switching than MQX and you've got a lot of support here.  I'm using the BM code as a basis in my FreeRTOS application and there has been no issues with it - if you look around, I posted my USB Task code on this forum.  

Just my $0.02.

[ErichStyger]

It should work with anything: bare metal, FreeRTOS or any other RTOS.

But I cannot comment on MQX as I have not used it, but I assume it should work too.

Erich

[balbet]

Perfect, thank you guys, we will try your recommendations and come back with the results to close this topic.

Thanks,