USB Data Mode


#1

Hello all,

I have a Q2686 or Q2687 with firmware R72 or 7.46 of which I am trying to use the USB port reliably in “Data Mode” (not AT Mode). Is the following procedure correct within an open at application:

Check USB port is enabled

1 Check if USB port is enabled with the at+wmfm=0,2,3 command,
1a On result equals at+wmfm=0,1,3,1 (go to 2, if not go to 1b).

Detecting USB cable plug in

2 Check to see if port is available with ADL function: adl_fcmIsAvailable(ADL_PORT_USB),
2a On result equals true subscribe to FCM using adl_fcmSubscribe(ADL_PORT_USB,CtlHdl,DataHdl) (ensuring an unsubscribe is performed first if already subscribed to). Go to 3 on event,
2b On result equals false repeat step 2 until result equals true (via a timer).

1b On result equals at+wmfm=0,1,3,0 (go to 1c)
1c Enable the port by sending the at+wmfm=0,1,3,1 command,
1d On trigger of 1c’s handler go to step 2

3 On event ADL_FCM_EVENT_FLOW_OPENNED call function adl_fcmSwitchV24State(DataHandle, ADL_FCM_V24_STATE_DATA) to convert the port to Data Mode.
4 After event ADL_FCM_EVENT_V24_DATA_MODE the USB is now ready for data transfer over the USB port.

5 On event ADL_FCM_EVENT_FLOW_CLOSED go to step 2.

The problem I am experiencing is that when plugging in the USB cable the OS system detects the USB device but the port on the device does not always change to data mode.

Any advice would be gratefully received

Regards


#2

AIUI, FCM is totally oblivious to the fact that UART3 is actually USB.

As far as FCM is concerned, it is just another UART - exactly like UART1 and UART2 - and it has no way to determine whether anything is actually connected to the port or not.

So you just subscribe the port, and switch it to data mode. If nothing is connected, you just won’t receive anything, and anything you send will just go nowhere.

Simples.


#3

Hi awneil,

Thanks for your response. I will by all means try (again) just subscribing to adl_fcmSubscribe function (without any “AT” command intervention), however, the last time I tried this the adl_fcmSubscribe fucntion always returned ADL_RET_ERR_BAD_STATE until I plugged in the USB cable. While I was receiving the bad state I did not receive an ADL_FCM_EVENT_FLOW_OPENNED event at any stage (as you would expect). Is it a case I have to loop (via a timer) on calling adl_fcmSubscribe until it succeeds? Do I have to use or adl_fcmIsAvailable in some way?

Regards

Barry


#4

Use adl_portSubscribe() in order to know, when USB cable is connected or disconnected. I believe, at+wmfm is no longer needed in this case. Instead, OpenAT informs you, when USB is available/unavailable.

s8 retVal = adl_portSubscribe(UsbPortHandler);
  ...
static void UsbPortHandler(adl_portEvent_e Event, adl_port_e Port, u8 State)
{
  if(Port == ADL_PORT_USB)
  {
    // USB available (USB cable connected to PC)
    if(Event == ADL_PORT_EVENT_OPENED)
    {
      retVal = adl_fcmSubscribe(ADL_PORT_USB, FcmCtrlHandler, FcmDataHandler);
      ...
      // Event ADL_FCM_EVENT_FLOW_OPENNED in FcmCtrlHandler() follows...
    }

    // USB unavailable (USB cable not connected to PC)
    else if(Event == ADL_PORT_EVENT_CLOSED)
    {
      // FCM is released automatically
      ...
    }
  }
}

Regards,
Oliver


#5

Hello olkae,

I have now tried the method you mention using adl_portSubscribe and works fine for OS Firmware v 7.46 with the exception that if I leave the cable plugged in during power up I do not get any adl_portSubscribe events until I unplug then plug the cable back in. I have also tried looping on adl_fcmIsAvailable (via a timer) until this becomes true (when the cable is plugged in) and then subscribing to FCM using the adl_fcmSubscription function, this also works fine for Firmware 7.46. None of the above options work reliably on Fimware v 7.2 for one reason or another.

When using the adl_portSubscribe function on 7.2 I never received any events for that port. If I loop on adl_fcmIsAvailable I always get false (when at+wmfm for USB is disabled) and always true when (at+wmfm for USB is enabled). I also do not get an ADL_FCM_EVENT_FLOW_CLOSED when removing the USB cable. Upon replacing the cable I am unable to communicate with the device in data mode again.

Is this a bug in OS Firmware 7.2? I have also tried Firmware 7.4 with identical results to 7.2.

We have a number of devices in the field which use OS Firmware 7.2 of which at present do not support DOTA2 (OS firmware updates) so getting the USB to work reliably for 7.2 is important.

Regards

Barry


#6

At https://forum.sierrawireless.com/t/com-port-management-still-needs-attention/5167/3 Sierra Wireless writes:

Hope, this will solve this problems at power up.

I read, that there has been lot of changes in the USB part of OpenAT. Probably this leads to the different behaviour between the 2 versions. Maybe you have to check the firmware version in your code and implement both ways…

Regards,
Oliver.


#7

I had partly the same problem until I did the USB initialization very early in the “main” function. The USB events are notified at plugging/unplugging the USB cable. Power-up is something like plugging the USB cable and I guess, the related USB events are notified by OpenAT quite early.

Regards,
Oliver.