CDC Interface in the new LUFA doesn't like two USB Modems

Log in or register to post comments
Go To Last Post
25 posts / 0 new
Author
Message
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
#1
Posted by ixremedy: Sun. Nov 11, 2012 - 11:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

I've copied this topic over from another older message. I hope that someone may help me find the solution:

Does anybody know why two USB modems may stop working with the new LUFA library? May it be compiler problems or anything else?
The first modem is Novatel Wireless the other one is Huawei E160. Both modems fail to get enumerated.
Tried three different GCC compilers and all existing optimization methods.
They just won't enumerate and with the E160 - it says that its a wrong CDC device.

Any suggestions?

The micro is AT90USB

Update: on Huawei E160 it isn't able to configure the pipes. Wasn't yet able to see what is wrong with the other one, but must mention that both modems work fine on a windows machine.

Update: it is not able to find a compatible data exchange interface (no notification endpoint???) with USB_GetNextDescriptorComp()

Update: GetNextDescriptorComp() tried to find a control interface using the comparator function DComp_NextCDCControlInterface() which went through the descriptors' headers (11 pieces) and found three with:
Class 255 SubClass 255 Protocol 255 StrIndex 0
But the first contained the flag TotalEndPoints with the value "3" and the other two had that value set to "2"

I guess this Class implies that the CDC interface realisation is manufacturer specific. But how come it worked before for both modems?

If I break the comparator function and make it hook up to an interface with the CLASS 255, the modem will be useless further on anyway:
if ((Interface->Class == CDC_CSCP_CDCClass || Interface->Class == 0xFF) && (Interface->SubClass == CDC_CSCP_ACMSubclass || Interface->SubClass == 0xFF) && (Interface->Protocol == CDC_CSCP_ATCommandProtocol || Interface->Protocol == 0xFF)) { return DESCRIPTOR_SEARCH_Found; }

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 01:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are the descriptors for the HUAWEI E160:
Device Descriptor:
bcdUSB: 0x0200
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40 (64)
idVendor: 0x12D1
idProduct: 0x1001
bcdDevice: 0x0000
iManufacturer: 0x03
iProduct: 0x02
iSerialNumber: 0x00
bNumConfigurations: 0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed: Full
Device Address: 0x01
Open Pipes: 7

Endpoint Descriptor:
bEndpointAddress: 0x81
Transfer Type: Interrupt
wMaxPacketSize: 0x0040 (64)
bInterval: 0x05

Endpoint Descriptor:
bEndpointAddress: 0x82
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x20

Endpoint Descriptor:
bEndpointAddress: 0x01
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x20

Endpoint Descriptor:
bEndpointAddress: 0x83
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x20

Endpoint Descriptor:
bEndpointAddress: 0x02
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x20

Endpoint Descriptor:
bEndpointAddress: 0x84
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x20

Endpoint Descriptor:
bEndpointAddress: 0x03
Transfer Type: Bulk
wMaxPacketSize: 0x0200 (512)
bInterval: 0x20

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 01:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And this is for the Novatel:
Device Descriptor:
bcdUSB: 0x0110
bDeviceClass: 0x00
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40 (64)
idVendor: 0x1410
idProduct: 0x2110
bcdDevice: 0x0000
iManufacturer: 0x01
iProduct: 0x02
iSerialNumber: 0x00
bNumConfigurations: 0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed: Full
Device Address: 0x03
Open Pipes: 5

Endpoint Descriptor:
bEndpointAddress: 0x81
Transfer Type: Interrupt
wMaxPacketSize: 0x0010 (16)
bInterval: 0x80

Endpoint Descriptor:
bEndpointAddress: 0x82
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x00

Endpoint Descriptor:
bEndpointAddress: 0x02
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x00

Endpoint Descriptor:
bEndpointAddress: 0x84
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x00

Endpoint Descriptor:
bEndpointAddress: 0x04
Transfer Type: Bulk
wMaxPacketSize: 0x0040 (64)
bInterval: 0x00

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 01:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've just payed attention to that USB View says the class, subclass and protocol are 0x00, whereas lufa says they are oxff (vendor specific).
Is it the GCC compiler that compiles the misfunctioning code? I've changed three versions...

Compiler optimization flags and the version certainly bring concerns... Depending on the optimization the modems start to initialize or they won't. Although as I wrote higher up, both modems have three interfaces with Class, Subclass and Protocol equating to 255 (0x00 by USBView).

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Nov 12, 2012 - 01:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're seeing the *device* class/subclass/protocol values as 0x00 with USBVIEW, but you are seeing 0xFF class/subclass/protocol values in the *interface* in LUFA. Those are two separate set of values, and it's perfectly fine that they are different (all 0x00 in the device descriptor just tells the PC to search the interface values instead).

Mike's AVRUSBMODEM project was tested against one or two models of USB modems, but unfortunately each new version seems to choose a different way of selecting between the virtual Mass Storage mode (for installing the drivers) and the CDC modem mode. That means that each model of modem that's used probably needs a few manual tweaks to get it running. The easiest way to do this is to just sniff the USB traffic when you plug in the modem to a PC, and ensure that you replicate that on the embedded platform to switch into the correct modem mode.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 05:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
You're seeing the *device* class/subclass/protocol values as 0x00 with USBVIEW, but you are seeing 0xFF class/subclass/protocol values in the *interface* in LUFA. Those are two separate set of values, and it's perfectly fine that they are different (all 0x00 in the device descriptor just tells the PC to search the interface values instead).

Well not exactly, USB view, as you can see on the printouts doesn't show that these two modems have any other interfaces (that would be listed as anything except 0x00). These two modems don't have internal storage for drivers or anything else.
Am I corrent to suppose that the IN,OUT and CONTROL pipes should be chosen from different interfaces?

And again, both modems worked with a previous version of LUFA (the february one), that's why I didn't investigate that deep into the library back then. I don't believe you've screwed your own code :)

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Nov 12, 2012 - 05:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There should be an option in USBVIEW to show the interface descriptors - it should have at least one.

One change between the two versions you mention is the move from pipe indexes to full pipe addresses, which is an issue if you are using old code. You will need to change these:

                /** Pipe number for the CDC data IN pipe */
                #define CDC_DATA_IN_PIPE           1

                /** Pipe number for the CDC data OUT pipe */
                #define CDC_DATA_OUT_PIPE          2

                /** Pipe number for the CDC notification pipe */
                #define CDC_NOTIFICATION_PIPE      3

To this:

                /** Pipe number for the CDC data IN pipe */
                #define CDC_DATA_IN_PIPE           (PIPE_DIR_IN | 1)

                /** Pipe number for the CDC data OUT pipe */
                #define CDC_DATA_OUT_PIPE          (PIPE_DIR_OUT | 2)

                /** Pipe number for the CDC notification pipe */
                #define CDC_NOTIFICATION_PIPE      (PIPE_DIR_IN | 3)

Before you ask, this change was to mirror the same change made to the endpoint indexes, which was required to support the XMEGA devices (experimental).

I'd like to update the USBModem project to support the latest LUFA but don't have a modem handy; if you can confirm this works I can update the SVN.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 05:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a very tight memory configuration with .data being in the main cpu memory, .bss in extended and another segment dedicated just for buffers in my project. So I suspect that may be the case. I am now looking at the avr-nm printouts.

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 05:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But how come it sees the interfaces 0xFF instead of 0x00? I cannot find an explanation...

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Nov 12, 2012 - 06:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I said earlier, USBVIEW is showing the device class values only, and not the interface values that the endpoints will belong to. There's an option to enable the display of interfaces and other descriptors inside USBVIEW.

Device class/subclass/protocol values of all 0x00 is perfectly legal, and just tells the OS to look at the each interface's class/subclass/protocol values instead to get the correct driver. Values of all 0xFF on the interface is what I would expect, as this indicates a vendor specific protocol being used on the endpoints (which prevents it from showing up as a regular virtual COM port). Interface class/subclass/protocol values of 0x00 would not be legal.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 06:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, event if they would not be valid and the LUFA library won't accept them. If to take for granted that I may have changed the value in the source code for the previous version to 0xFF, how did it work?
Now after I changed the evaluation to accept 0xFF, and it takes the interrupt interface for NOTIFICATION, a BULK interface for OUT and another one for IN, why when it sends an AT command the modem won't respond?
Can any IN and OUT interface - respectively to the purpose, be used to communicate commands and data traffic with the modem, or just the ones that are 0x01, 0x02 and 0x03?

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Nov 12, 2012 - 06:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, I missed that you had checked it against the old LUFA library.

What version of LUFA did you use before that worked? Are you using LUFA-120730 now, or the SVN release? If you reload the old binary file, does the modem still work?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 06:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It takes address 129 (valid, according to UsbView) for Notification, address 130 for DATA IN and address 1 for DATA OUT.
Then it tries to send AT commands and the modem keeps silent

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 06:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I am using the version you said 120730 (since I don't have SVN installed on my windows PC :)
I can reinstate the old library, but I won't find that old code of mine :(
I think If I manage to find out whether the IN, OUT and NOTIFICATION pipes assignments are valid and put them in the right order, everything should work just fine. Again, I don't believe that you broke the code :)

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Nov 12, 2012 - 06:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's possible that some interfaces have moved around since the last USBModem revision - it all depends on what the old (working) version of LUFA was. Given a release ID, I can diff between it and the latest release and see if there are any likely areas that could have caused the old USBModem code to break.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 06:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That was the "stable" version of February this year.

/** Indicates the version number of the library, as an integer. */
#define LUFA_VERSION_INTEGER 0x120219

/** Indicates the version number of the library, as a string. */
#define LUFA_VERSION_STRING "120219"

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 07:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It has even enumerated my old Sony Ericsson P1i. But still, took 129 for Notification, 130 for IN, 2 for OUT, sends commands to it and the phone won't say anything in response.

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 07:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've put the old code back in, out of order :( Although it said that my SonyEricsson P1i wasn't a valid CDC Class device with the other two modems being the right CDC Class. It sends a command and the modem doesn't respond.

Now I am completely upset ;(

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 07:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have found the old Firmware .elf file, burnt it in, and the Novatel Wireless has connected to the internet right away...

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 07:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Got it working with the old stuff, the February version.

Reverted back to the older functions and defined the next global CDC_Host interface:
USB_ClassInfo_CDC_Host_t VirtualSerial_CDC_Interface =
{
.Config =
{
.DataINPipeNumber = 1,
.DataINPipeDoubleBank = false,

.DataOUTPipeNumber = 2,
.DataOUTPipeDoubleBank = false,

.NotificationPipeNumber = 3,
.NotificationPipeDoubleBank = false,
},
};

So this means that the auto detect doesn't really work for CDC yet, it somehow chooses the wrong communication endpoints.

Last Edited: Mon. Nov 12, 2012 - 07:56 PM
Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Nov 12, 2012 - 07:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you send me your project files? You can email a zip of them to me (dean at fourwalledcubicle dot com) and I can then see if there's anything obvious in the interfaces being used. I did a diff between the two versions of LUFA and nothing jumped out at me as being problematic other than the pipe addresses, but seeing your code would help.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 07:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You won't get it working, you don't have our hardware :)

By they way, if we run tests for a couple of months and it works for us, we'll buy the license.

Last Edited: Mon. Nov 12, 2012 - 08:00 PM
Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Nov 12, 2012 - 07:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope, but I will be able to see what LUFA functions/code you are using, which narrows down the possibility of what could break between versions.

- Dean :twisted:

(If it's an IP problem don't worry, I'm happy to sign an NDA)

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 08:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We'll find a way to sort out this code exchange problem :)

Top
ixremedy
ixremedy's picture
Level: Wannabe
Joined: Sun. Nov 11, 2012
Posts: 98 View posts
Posted by ixremedy: Mon. Nov 12, 2012 - 08:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What I still don't understand is why it takes so much time to attach a device. I've tried to fiddle with -D HOST_DEVICE_SETTLE_DELAY_MS, now it is 200. I'll change it to 30 and see how that shows up

Top