Author Topic: CDC Data Interface Class  (Read 20330 times)

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: CDC Data Interface Class
« Reply #15 on: March 17, 2014, 02:05:39 pm »
You couldn't find the file or you didn't see anything useful in it?

Support for SEND_ENCAPSULATED_COMMAND and GET_ENCAPSULATED_COMMAND is required for abstract control model devices. However, if AT commands aren't implemented, the host has no reason to send these requests.

Support for the other requests are optional. If not supported, the device should return STALL.

Nik

  • Member
  • ***
  • Posts: 40
Re: CDC Data Interface Class
« Reply #16 on: March 17, 2014, 02:14:50 pm »
Jan I could not find the file at C:\WINDOWS\setupapi.log

In my case, as I only need to send and receive raw bytes from the VCOM port, is Abstract Control Model ?

Secondly, I thought that these requests are post enumeration events. So at least my device should enumerate properly.

What am I missing ?  :'(



Regards,
Nik

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: CDC Data Interface Class
« Reply #17 on: March 17, 2014, 02:27:20 pm »
Look in windows\inf

Yes, use abstract control model for virtual com port.

The device has enumerated successfully if endpoint 0 has ACKed a Set_configuation request > 0.


Nik

  • Member
  • ***
  • Posts: 40
Re: CDC Data Interface Class
« Reply #18 on: March 17, 2014, 02:51:14 pm »
Jan,

Apparently, there is no SET_CONFIGURATION request in my case.

Could not my hardware analyzer report with the reply.

Nik

  • Member
  • ***
  • Posts: 40
Re: CDC Data Interface Class
« Reply #19 on: March 17, 2014, 03:25:37 pm »
As the enumeration is failing, there is no data logged in setupapi.dev.log


Nik

  • Member
  • ***
  • Posts: 40
Re: CDC Data Interface Class
« Reply #20 on: March 17, 2014, 04:38:17 pm »
Here is one more observation :

When the config descriptor is <= 64, the device enumerates but the virtual com port shows : Error (code 10).

But if the config descriptor is >64, the device does not enumerate.

So, clearly it is an issue of greater than 64 bytes packet. However, I think I am sending it the way it is supposed to be.


- Nik

Barry Twycross

  • Frequent Contributor
  • ****
  • Posts: 263
Re: CDC Data Interface Class
« Reply #21 on: March 17, 2014, 05:03:16 pm »
Hi Barry,

Thanks for your time.

This is what the hardware analyzer is showing :
  Host sends    : Get config descriptor request
  Device sends : ACK
  Host sends    : IN Token
  Device sends : 64 bytes config data
  Host sends    : ACK
  Host sends    : IN Token
  Device sends : 3 bytes config data
  Host sends    : ACK
  Host sends    : OUT Token
  Host sends    : 0 byte data
  Device sends : ACK

Is there any issue here
That would depend on the toggle of the data packets. The 64 byte packet should have DATA1 (all SETUP transfers start with a DATA1), the 3 byte packet should have DATA0 (toggles should alternate except the first one). That the host sends the OUT token is a good sign, unless its substantially later than the 3 byte packet. With a bad data toggle, the host would accept the packet, and discard it. Then you'd see further IN tokens, which would probably be NAKed. After sometime NAKing, the host can timeout and send the OUT token. The timeout is probably between 500ms and 5s.

Nik

  • Member
  • ***
  • Posts: 40
Re: CDC Data Interface Class
« Reply #22 on: March 17, 2014, 06:21:00 pm »
Hi Barry,

Yes the 64 bytes have DATA1 and 3 bytes have DATA0.

The OUT token sent by the host is after 2msec.

But after receiving the first 64 bytes the host sends ACK. Then host send 42 IN Tokens which are NAKed and at 43rd IN Token, the device sends rest of the 3 bytes.


Thanks.
Nik
« Last Edit: March 17, 2014, 06:26:39 pm by Nik »

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: CDC Data Interface Class
« Reply #23 on: March 18, 2014, 10:13:34 am »
Be sure bInterfaceClass in the Device desrcriptor = 2.

If you have changed your descriptors over time, change the Product ID, as Windows will "remember" previous descriptors.

Nik

  • Member
  • ***
  • Posts: 40
Re: CDC Data Interface Class
« Reply #24 on: March 18, 2014, 11:29:06 am »
Jan, Barry and everybody else !

Issue fixed !

The issues was - delay in sending the remaining 3 bytes of config descriptor data.
After sending first 64 bytes, I was checking the interrupt bit to make sure if the 64 bytes have been sent.
Removing this check fixed it !

Here is the code of sending config descriptor :


if ((desclen!=0))                  // one of the case statements above filled in a value
  {
    sendlen = (reqlen <= desclen) ? reqlen : desclen; // send the smaller of requested and avaiable

    //Send length is less than or equal to 64
    if(sendlen<=64)
    {
      WriteBytes(rEP0FIFO,sendlen,pDdata);
      WriteMax3421RegAS(rEP0BC,sendlen);   // load EP0BC to arm the EP0-IN transfer & ACKSTAT
    }

    //Send length is greater than
    else
    {
      do
        {
           sendlen = 64;
           WriteBytes(rEP0FIFO,sendlen,pDdata);
           WriteMax3421RegAS(rEP0BC,sendlen);   // load EP0BC to arm the EP0-IN transfer & ACKSTAT
           desclen=desclen-sendlen;
           pDdata=pDdata+sendlen;

        }while(desclen>64);

      sendlen = desclen;
      //while(!ReadMax3421Reg(rEPIRQ& bmIN0BAVIRQ));

      if(sendlen>0)  WriteBytes(rEP0FIFO,sendlen,pDdata);
      WriteMax3421RegAS(rEP0BC,sendlen);

    }


Commenting the line in red worked for me.

Thank you all for your precious time !

Regards,
Nik
« Last Edit: March 18, 2014, 11:30:44 am by Nik »

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: CDC Data Interface Class
« Reply #25 on: March 18, 2014, 11:49:49 am »
Glad you got it fixed. Thanks for letting us know what you found!