USB Problem with 7.45 firmware

Legacy Open AT
1

Hello,

I am using a Q2687 refreshed running an Open-At aplication.
I need to use the USB port as a UART, like before (7.44), but there isn´t example in the ADL 6.35 documentation.
In the developer studio i found 2 examples but they use the USB port as a “Mass Storage Device” and a “Audio Device”.
Can anyone send me an example of a UART implementation with the USB port in 7.45 firmware?.

Thanks.

2

If you’re just using it as a UART - for FCM or AT Commands - then it is just UART3, and works exactly the same as UART1 and UART2.

3

If you want just normal UART – there is no change. just make sure it is enabled (see AT+WMFM command). By default, USB is disabled.

If you want to use it in OpenUART mode, it gets complicated. With 7.45, OPENUSB was introduced, so you have to configure and start OPENUSB subsystem before you can run OPENUART on top of it.

Rudolf

4

Is it :question:

Have they changed it back again?

5

Hi,

In the Open-AT Aplication I´m doing this:

rta = adl_atCmdCreate("AT+WMFM=0,1,3", ADL_AT_PORT_TYPE( ADL_PORT_UART1, TRUE ),(adl_atRspHandler_t)ATUSBHandler,"*",NULL);

Response “OK”, the usb is open, next:

uart[Port].PortID = adl_fcmSubscribe(ADL_PORT_USB, CtrlUSBHandler, DataUSBHandler);

Port subscribe.
But the adl_fcmSubscribe response is:

uart[Port].PortID = ADL_RET_ERR_BAD_STATE

In version 7.44 that code works.
Thanks.

6

Is that the return value from the adl_atCmdCreate() call, or the actual response from the AT command :question:

Aside:

I strongly recommend that you do not cast the handler argument like that!

  • If the type is correct, it is unnecesary and just clutters the code;
  • If the type is not correct, it will prevent the compiler from warning you - and possibly lead to some obscure and hard-to-debug problems…
7

Thanks for the recomendation!

“OK” is the return value of adl_atCmdCreate().

“ADL_RET_ERR_BAD_STATE” is the return value of adl_fcmSubscribe().

Thanks.

8

So what is the response to the AT command?

Do you wait for the response to the AT command before attempting the FCM subscription… :question:

9

The response to the AT command is “OK”.
Yes I wait the response before attempting the FCM subscription.

I think there are no problems in the code because this Open AT aplication works with 7.44, is the firmware of a device that we sell since a long time and I try only to change de Sierra Wireless firmware.

Thanks.

10

Unfortunately, that does not prove that your code was correct!

You may be right, but there are plenty of cases where flawed code has been shipped & “working” i[/i] for years, and something like a firmware update brings the flaw to light.

11

Ok, thanks, I will keep working on it!

A last question, do you use the USB port in 7.45? not for AT commands.

12

No, I haven’t used it yet.

13

I have used the USB port with R7.45 and SL6087 without any issues.
Both in normal AT mode and FCM DATA mode.

14

Here is the solution:

To subscribe the USB, the cable must be connected and must wait a few seconds between the open and the subscribe.

In Fw7.44 works without that, but no in 7.45 and 7.46.

Thanks!

15

I take it back.
R7.45 USB does not work without issues. (SL6087 and Q2687RD)

After more extensive testing I have found that it randomly simply stops sending anything in either AT or FCM DATA mode.
Sometimes it’s right at powerup it simply doesn’t send anything.
Sometimes it’s during communication it simply stops sending anything over USB.

Using USB Explorer 200 from Ellisys I can’t see any reason for this behaviour when compared to previous firmware versions.

Testing on R7.46 is about to commence.

16

And I just got the same issue on R7.46 as well…

17

I may have to eat my own words again…

Upon further review of the test results, I realized that I still can’t determine conclusively if the problem is on the device side or if it’s on the host side.
Timing changes on the device side might have triggered unforeseen effects on the host side, which in this case is not a PC USB controller.

18

I’ve now managed to reduce my USB issues with 7.45 and 7.46 to one that shows up when USB is in FCM DATA mode.

In short, there is random packet loss when sending data to the module. It doesn’t happen often, but often enough to disrupt my XModem transfers
That data is actually sent over USB has been verified using Ellisys USB Explorer 200.

This random packet loss has not been observed with R7.2a and R7.44.

19

Hi,

Are you sure you see the problem on 7.46, because there was a problem with USB in FCM data mode in 7.45, but this was resolved in 7.46 .

20

I’m sure that I had packet loss (or what appeared to be packet loss) with R7.46 as well.

It is no longer a problem for me however due to additions in my routines that detect those stalls and attempts to resume the transfers. (Something that I should have done either way)