USB CDC WorngPID error

Are you really hitting the CDC-ACM bulk IN/OUT endpoints of the cellphone?
Some Nokia cellphones expose composite device over USB.
Also, it may change configuration on full-speed bus from high-speed bus.

Read out Device and Configuration descriptor set from the cellphone over MAX3421E

OR

Read out the descriptors on a PC over a legacy (USB1.1) hub.

Tsuneo

Thank you so much for your time!!

I already do that, sniff usb packets with snoopPro and when i order the phone to send "hello World", i get it from BulK-IN endpoint address 0x8c, which is this i'm sending for, requesting the data. i also get the device descriptor.

I think i'm so close, because i see a kind of communication when a i send "hello world" from phone and MAX3421E change his behavior changing the error returned to atmega.

I believe this error is somehow related with diferent speed settings which is corrupting the packet PID, but i don´t know how to debug this error.

Best Regards

Nuno Fialho

> sniff usb packets with snoopPro

Is it done over a USB1.1 hub?
When the phone is connected to a PC USB port directly, or over a USB2.0 hub, the phone exposes high-speed configuration. But when it is connected to MAX3421E, full-speed configuration appears. There is no guarantee that both configurations assign the same endpoints to the CDC interfaces.
USB1.1 hub forces the bus speed to full speed. And then, you can see the full-speed configuration of the device on your PC.

> Do i need to Send a Set_CodingLine according with what speed??

I'm not sure.
Following the CDC-ACM spec strictly, Set_Line_Coding request doesn't affect USB side at all. It sets up UART on the device, if any. But there are so many variation on the device implementations. Some device implementation may assign additional function to the request, apart from the original spec.

It's better to examine the minimum requirement of the USB request on your PC.
Make a simple PC application using Win32 serial API, which can communicate with the phone.
And boil it down into minimum one.
For example,

                                     // open the COM port - no request on the USB side
    HANDLE hCOM = CreateFile("\\\\.\\COM7", GENERIC_READ | GENERIC_WRITE, 0, 0,
                             OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

                                    // set baudrate, parity, etc.
                                    // SetCommState() generates Get_Line_Coding, Set_Line_Coding
                                    // and Set_Control_Line_State requests
    DCB dcb;
    dcb.BaudRate = 115200;
    dcb.Parity   = NOPARITY;
    dcb.ByteSize = 8;
    dcb.StopBits = ONESTOPBIT;
    BOOL result = SetCommState( hCOM, &dcb );

                                    // assert DTR
                                    // EscapeCommFunction() puts Set_Control_Line_State
    EscapeCommFunction( hCOM, SETDTR );

                                    // send data to the device
                                    // WriteFile() generates bulk OUT transfer
    BYTE sampleData[16] = { 0x01, 0x02, ... };
    DWORD bytesWritten;
    WriteFile( hCOM, sampleData, 16, &bytesWritten, NULL );

                                    // read data from the device
                                    // ReadFile() puts no USB request, it reads RX buffer on the device driver
                                    // PC device driver repeats bulk IN transfer, separately, to fill the RX buffer
    DWORD bytesRead;
    ReadFile( hCOM, sampleData, 16, &bytesRead, NULL);

                                    // de-assert DTR
                                    // EscapeCommFunction() puts Set_Control_Line_State
    EscapeCommFunction( hCOM, CLRDTR );

                                    // CloseHandle() puts Set_Control_Line_State
    CloseHandle( hCOM );

Does it still work without SetCommState() and/or EscapeCommFunction() ?
When you get the minimum one, trace the USB request sequence on a sniffer
And implement the sequence to MAX3421E

Tsuneo