USB Host CDC Support in MQX?

[steve32768]

We're designing a board based on the Kinetis K60. The K60 only has 5 UARTs, and we need to interface to 7 UART devices, so there is a lack of serial ports. We're looking into the possibility of using a USB-to-serial converter chipset to add a couple more UART interfaces to the board. The USB side of the converter would be wired into the K60, and the K60 would act as the host.

The MQX v3.6.3 release notes indicate that there's support for the USB Host Communication Device Class (CDC), so I think we're covered, so long as we can locate a suitable USB-to-serial converter chipset that supports the USB CDC.

I've taken a look at a couple converters (FTDI FT232R, and Silicon Labs CP2105), but I don't see any indication that either of these support USB CDC.

My questions are: Has anyone attempted anything like this before? If so, what type of USB-to-serial converter chipset was used, and what was the result?

Ideally, I'd like to obtain a list USB CDC chipsets that are officially supported by (or at least tested with) MQX. Perhaps the Freescale folks can help out with this one?

-Steve

[FredericoPrado]

I can't find this 3.6.3 release. The last one I can find for download at the moment in the official page is the 3.6.2.

I have been trying to make the USB Host to work with a CDC ACM device (an external modem) without success for the last few days.

Apparently the CDC Serial example  for the USB host isn't working and the device initialization locks down its task. After a lot of debugging I was able to find out the deadlock, but even after the cause is removed and the initialization completes, as soon as I open the USB I start to receive NAK packages continuously and apparently I can't send or receive enything else.

Bottomline is, unless there is indeed a 3.6.3 versiona nd they fixed the problems in this version you won't likely be able to use the CDC host and neither will I.

[steve32768]

Sorry, that was a typo. I meant to say MQX v3.6.2.

[steve32768]

> Bottomline is, unless there is indeed a 3.6.3 versiona nd they fixed the problems in this version you won't

> likely be able to use the CDC host and neither will I.

Thanks for the information, and sorry about the confusion about the version number. It sounds like I should start looking at a plan B, since USB CDC Host funtionality/stability in MQX may be less than desirable.

JuroV: The purpose of my post was to collect information on USB CDC in host mode (not to report a bug). However, it looks like Frederico is experiencing a bug while attempting to use it.

[JuroV]

Hello guys,

are you reporting bug? Please describe what is not working: symptomps, occurences, log and trace reports etc.

Thanks.

[FredericoPrado]

Hello, JuroV.

The description of the problems follows bellow.

I am trying to use the Serial CDC Host example to connect to a GPRS Modem by USB using the MC52259DEMO board. I tried it with several modems including the Motorola H24, G24 and my CellPhone.

The attachment proccess starts and goes smoothly until "usb_class_cdc_get_acm_line_coding" is called in "usb_host_cdc_data_event".

After a lot of debugging I was able to pinpoint the motive.

USB requests are proccessed by  "_usb_khci_task" in my board. This task reads a task queue, processes the current task if the queue is not empty and calls "_usb_khci_process_tr_complete" when the task is completed.

"_usb_khci_process_tr_complete" in turn calls back the task callback function.

The deadlock is created as follows:

- "_usb_khci_process_tr_complete" is called and executes "usb_host_cdc_data_event" with the event code <USB_INTF_EVENT>.

 - "usb_host_cdc_data_event" calls "usb_class_cdc_get_acm_line_coding"

- "usb_class_cdc_get_acm_line_coding" enqueues a new USB task and waits for it to callback "usb_class_cdc_cntrl_callback" through the following line of code: <_lwevent_wait_ticks(event, USB_ACM_CTRL_PIPE_FREE | USB_ACM_DETACH, FALSE, 0);>

- Unfortunately the callback would be called by  "_usb_khci_task" which is blocked by its execution of "usb_class_cdc_get_acm_line_coding", so it will never happen, thus the deadlock.

Well, I fixed the problem above by not waiting the event and thus releasing the flow. Apparently it was enough to conclude the device initialization (the complete DEBUG_LOG_TRACE goes as attachment). But as soon as I open the USB with fopen it starts to continuously receive data packages of 192 bytes with are interpreted as NAK by the driver and discarded generating am error 151(USBERR_TR_FAILED ).

At this point I am unable to send ot receive any information from the device.

[JuroV]

Hello Frederico,

the bug you are describing first was already fixed in the newest release (MQX EAR 3.7.0).

If you start to receive data and if you get less data as expected, you are notified by error status that you did not received all data. But, buffer in callback is not NULL, that means, that you got some data. Is that your case?

[FredericoPrado]

Hello , Jurov.

I am glad to know that the deadlock will be fixed in the next release.

I am not sure if the following problem I described has to do with my work around or not but that aside the problem I am expecting is as follows:

- As answer to the package sent by "usb_class_cdc_get_acm_line_coding"  a package of 10 bytes is received (required=10; remain=10 and "_usb_khci_atom_tr" returns 10 ):

A1 20 00 00 00 00 02 00 02 00

- After this package the initialization is completed and I open the usb interface:

const CDC_SERIAL_INIT usb_open_param = { USB_UART_NO_BLOCKING  |  USB_UART_HW_FLOW };

 (f_usb = fopen("tty0:", (pointer) &usb_open_param)

As soon as the interface is opened I keep receiving a package of supposedly 192 bytes (required=192) which returns an error whenever "_usb_khci_task" tries to read it through "_usb_khci_atom_tr". Tthe return code is KHCI_ATOM_TR_NAK(-256 ).

This keep happening continuously and no other data is transmited to or received from the device.

I've tested it with several devices which should be CDC/ACM devices (Motorola H24 and G24 modems and a couple of cell phones). The result is always the same.

Any light shed on this subject would be highly appreciated.

Regards,

Fred

[FredericoPrado]

Just one more thing. The behavior is exactly the same with Hardware Flow Control disabled.

[JuroV]

I still don't understand it correctly. The CDC should scan for data and if no data is available, the NAK is responded from a device. This is normal (correct) operation. If the KHCI returns NAK error for a transaction and really nothing was sent from device, this is normal operation.

[FredericoPrado]

My knowledge about specifics from the USB protocol is limited to say the least, so I really can't tell if something is "normal" or not, JuroV.  What I do know is that once the stack receives the answer to usb_class_cdc_get_acm_line_coding it keeps receiving those NACK packages at a very hgih frequency and only those packages. If that is the normal behavior when the line is idle, fine, but unfortunately no other package is ever received, there is no communication with the devices, and I don't have a clue about why at this point. The same devices answer just fine to AT commands once plugged into a PC with Windows XP.

I have identified the deadlock in the initialization I pointed in the first message and worked around it and at least this seems to be working fine. In the debug log I've sent attached to one of my previous messages you can check all the initialization process if you wish.

Have you in Freescale at any point been able to talk to a modem with your stack? It is pretty obvious that nobody even tried as of the release 3.6.2 because it simply couldn't possibly work with that deadlock. Have you tried now after you fixed in your last internal release (3.7)? If so and if that works, when 3.7 will be available for download? If you didn't, on the other hand, I advise you to check deeper into it, because as I describbed above, the deadlock was not the only problem accordingly to my tests.