TWR-K40X256 - MQX with Processor Expert enabled BSP - CDC Virtual COM demo - device will not enumerate

[niroc]

The USB CDC Virtual COM demo (cdc_vcom_twrk40x256) that ships with MQX 3.7 stops working (device will not enumerate) as soon as MQX 3.7 is updated to use the Processor Expert Logical Level Device Driver enabled BSP (bsp_twrk40x256_pe) instead of the default BSP (bsp_twrk40x256).

My configuration:

Operating System: Windows XP SP2 

                       IDE: CodeWarrior 10.1

                   RTOS: MQX 3.7

After a clean installation of CW 10.1 and MQX 3.7...

Steps to reproduce USB CDC device enumeration problem:

1. Verify that the CDC Virtual COM demo (cdc_vcom_twrk40x256) works.
2. Import and rebuild bsp_twrk40x256_pe and psp_twrk40x256.
3. Rebuild cdc_vcom_twrk40x256.
4. Verify that the CDC Virtual COM demo no longer works (device will not enumerate).

I did a clean build of all MQX libs and the device will still not enumerate.

bsp_twrk40x256_pe

psp_twrk40x256

mfs_twrk40x256

rtcs_twrk40x256

shell_twrk40x256

usb_ddk_twrk40x256

usb_hdk_twrk40x256

Any ideas?

[niroc · Accepted solution]

See the following posting for the solution:

https://community.freescale.com/message/89074#89074

[aerodame]

This may or may or may not be related, but I am having problems with opening serial ports between simple terminal apps like TeraTerm and a C# windows program that utilizes the Serial Port API within Visual Studio. 

I've tracked this problem down to code in the top part of USB_Notif_Callback.  This start_transactions variable only gets set if there is an event_type = 24 (USB_APP_CDC_DTE_ACTIVATED).  Although this makes good sense, opening up a port in Visual Studio sends a sequence (three times) of 22, 23.  (USB_APP_CDC_CARRIER_ACTIVATED), (USB_APP_CDC_DTE_DEACTIVATED).  If event_type = 24 is never sent, then the port will stall on attempting to write a character, and then throw an exception if any additional characters are send after the first.

void USB_Notif_Callback(uint_8 event_type,void* val,pointer arg)
{
    uint_32 handle;
    uint_8 index;
   
    handle = *((uint_32 *)arg);
    if(start_app == TRUE)
    {
        if(event_type == USB_APP_CDC_DTE_ACTIVATED)
        {
           start_transactions = TRUE;       
        }

...

Using TeraTerm, when opeing up a COM port sends 22 (USB_APP_CDC_CARRIER_ACTIVATED) ,24 (USB_APP_CDC_DTE_ACTIVATED), which makes good sense.  So this appears to be a limitation of Visual Studio.  I'm looking into how to change this behavior if at all possible within the serial windows driver.

[ryanlush]

I know this post is 4.5 years old but did you ever find a solution? I am having the exact same issue.

[MVa]

Verify the USB clock frequency in the CPU component. See" CPU component \ Clock configurations \ Clock configuration 0 \ System clocks \ PLLFLL clock selection \ USB clock settings \ USB clock". USB module requires 48 MHz clock . .

[niroc]

The clock settings are set correctly. Seet attached screenshot of my settings. I did not modify these settings at all after a clean install of MQX 3.7, which means the settings in my screenshot represent the settings that ship with MQX 3.7.

I contacted a Freescale rep. and received the following as the reply:

"Have Robotronics run the demo file in C:\Program Files\Freescale\Freescale MQX 3.7\usb\device\examples\cdc\virtual_com\cw10 When run, they will be asked to install a .inf file for the CDC.  It’s in C:\Program Files\Freescale\Freescale MQX 3.7\usb\device\examples\cdc\virtual_com\inf Run both the P&E Terminal Program (which reports status) and open a terminal program (Hyperterm, PuTTY, TerraTerm) using the COM port assigned by Windows."

The P&E Terminal is not necessary to successfully run the CDC demo (cdc_vcom_twr40x256) using the default BSP and

attaching the P&E Terminal to the USB COM to monitor status didn't help solve the problem when using the Processor Expert enabled BSP. The P&E Terminal reported no status while flashing the processor or when attempting to enumerate the tower module as a CDC USB device.