K22 + MCUxpesso and CDC Virtual COM Port example

cancel
Showing results for 
Search instead for 
Did you mean: 

K22 + MCUxpesso and CDC Virtual COM Port example

413 Views
balbet
Contributor II

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!

0 Kudos
10 Replies

398 Views
ErichS
Senior Contributor III

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

0 Kudos

395 Views
balbet
Contributor II

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!

0 Kudos

406 Views
mjbcswitzerland
Specialist V

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

 

0 Kudos

396 Views
balbet
Contributor II

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,

0 Kudos

384 Views
mjbcswitzerland
Specialist V

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

 

0 Kudos

391 Views
ErichS
Senior Contributor III

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

0 Kudos

387 Views
balbet
Contributor II

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,

364 Views
myke_predko
Senior Contributor III

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

368 Views
ErichS
Senior Contributor III

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

350 Views
balbet
Contributor II

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

Thanks,

0 Kudos