No! This thread can't end here. You guys were about to tell me where to put the GUID!
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Ed@BGM)
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (newfound)
Ha, ha! That is quite a post. :) I have not (as yet) used the MS OS descriptors and cannot help myself but if you have a look at the M-STACK source code by Alan O his example might just help.
Find it here: http://www.signal11.us/oss/m-stack/
Find it here: http://www.signal11.us/oss/m-stack/
↧
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Jim Nickerson)
Ian has some answers about your posting fun NEW USERS: Posting images, links and code - workaround for restrictions.
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Martin Franke)
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Jim Nickerson)
↧
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Jim Nickerson)
Martin,
You might try opening a support ticket to request Microchip make changes to Harmony.
You might try opening a support ticket to request Microchip make changes to Harmony.
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Martin Franke)
Thank you Jim, I tried but must have missed something when adding the code and end code statements. Appreciate the help!
Martin
Martin
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Martin Franke)
Jim,
I'll look into opening a support ticket for this. Appreciate your help.
Martin
I'll look into opening a support ticket for this. Appreciate your help.
Martin
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Tez)
This will be considered as a feature request. Are you able to get the system to work with what you have done above. Would you be okay if the setup request for this descriptor is forwarded to the application as a control transfer request and if the application responds to this request?
↧
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Martin Franke)
Hello Tez,
I'm afraid I've been busy with other things and haven't pursued the other method I described yet (I also kind of wanted to hear back first). Letting the app deal with as a control transfer request would be perfect. I think this would require a change in the harmony files because the app will currently never get that request as best as I can tell. FYI I did post this as a ticket item 280970 and was informed it would be considered.
Thanks for your support!
Martin
I'm afraid I've been busy with other things and haven't pursued the other method I described yet (I also kind of wanted to hear back first). Letting the app deal with as a control transfer request would be perfect. I think this would require a change in the harmony files because the app will currently never get that request as best as I can tell. FYI I did post this as a ticket item 280970 and was informed it would be considered.
Thanks for your support!
Martin
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Tez)
Thank you for the feedback. The USB Device Stack API is v1.0 now and so cannot change. We will try to find a way to accommodate this without breaking existing applications. We may also be able to forward this request directly to the application as a control transfer request. The application must register an event handler with the device layer for this. Do you have a production schedule that you are trying to meet?
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Martin Franke)
Hello Tez,
Thank you for considering accommodating this with Harmony. I guess for a deadline it would be nice if this could be accommodated in a month or so, but I'm not really in a pinch probably until the end of the year and we've made some other changes that is pushing this out a bit anyway. Thanks!
Thank you for considering accommodating this with Harmony. I guess for a deadline it would be nice if this could be accommodated in a month or so, but I'm not really in a pinch probably until the end of the year and we've made some other changes that is pushing this out a bit anyway. Thanks!
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (MaxVA)
Hello Martin,
About a year ago I made my own WINUSB stack on a PIC18F2550 using the 0xEE string index (and the extended compatibility descriptor and extended properties descriptor). Now I am in the hard battle of doing the same in Harmony for a PIC32 and I am having a bad time trying to fit that in Harmony without disrupting it. Can you post your code relating the 0xEE string index, extended compatibility descriptor and extended properties descriptor? Thanks in advance!
About a year ago I made my own WINUSB stack on a PIC18F2550 using the 0xEE string index (and the extended compatibility descriptor and extended properties descriptor). Now I am in the hard battle of doing the same in Harmony for a PIC32 and I am having a bad time trying to fit that in Harmony without disrupting it. Can you post your code relating the 0xEE string index, extended compatibility descriptor and extended properties descriptor? Thanks in advance!
↧
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Martin Franke)
Hello Max,
I wish I could be more help. We ended up making a major change to this project that has pushed it out and I have been focusing on hardware and postponed looking into this as I had a workaround using a custom .inf file and disabling driver signature enforcement for now. I was hoping maybe possibly it would be added to Harmony by the time I got back to it. Now we've ended up switching to another CPU because of RAM and ADC limitations. I did however receive the below response in my ticket that may be helpful. It seems Microchip added the Microsoft string descriptors to MLA but not to Harmony! I posted the MLA descriptors below as well for reference.
Sorry I could not be more help!
Martin
Microchip Ticket Support:
The "MLA" (Microchip Library of Applications) which provides software stacks on USB, TCP/IP, Graphics etc. for 8 & 16-bit PICs (so the PIC32 is not included anymore, since it uses Harmony now), also has an example for WinUSB supporting the new feature you described.
In case you wish to see how it's been implemented, you could do this:
> Download & install the MLA (latest version!), or at least the USB Framework & examples from its installation menu:
> Open the MPLAB X demo located by default under:
C:\microchip\mla\v2014_07_22\apps\usb\device\vendor_basic\firmware
> Look for the “IMPLEMENT_MICROSOFT_OS_DESCRIPTOR” configuration option. You can see the vendor specific descriptor in usb_descriptors.c
MLA Descriptors:
//Microsoft "OS Descriptor" - This descriptor is based on a Microsoft specific
//specification (not part of the standard USB 2.0 specs or class specs).
//Implementing this special descriptor allows WinUSB driver package installation
//to be automatic on Windows 8. For additional details, see:
//
const MS_OS_DESCRIPTOR MSOSDescriptor =
{
sizeof(MSOSDescriptor), //bLength - lenght of this descriptor in bytes
USB_DESCRIPTOR_STRING, //bDescriptorType - "string"
{'M','S','F','T','1','0','0'}, //qwSignature - special values that specifies the OS descriptor spec version that this firmware implements
GET_MS_DESCRIPTOR, //bMS_VendorCode - defines the "GET_MS_DESCRIPTOR" bRequest literal value
0x00 //bPad - always 0x00
};
//Extended Compat ID OS Feature Descriptor
const MS_COMPAT_ID_FEATURE_DESC CompatIDFeatureDescriptor =
{
//----------Header Section--------------
sizeof(CompatIDFeatureDescriptor), //dwLength
0x0100, //bcdVersion = 1.00
EXTENDED_COMPAT_ID, //wIndex
0x01, //bCount - 0x01 "Function Section(s)" implemented in this descriptor
{0,0,0,0,0,0,0}, //Reserved[7]
//----------Function Section 1----------
0x00, //bFirstInterfaceNumber: the WinUSB interface in this firmware is interface #0
0x01, //Reserved - fill this reserved byte with 0x01 according to documentation
{'W','I','N','U','S','B',0x00,0x00},//compatID - "WINUSB" (with two null terminators to fill all 8 bytes)
{0,0,0,0,0,0,0,0}, //subCompatID - eight bytes of 0
{0,0,0,0,0,0} //Reserved
};
//Extended Properties OS Feature Descriptor
const MS_EXT_PROPERTY_FEATURE_DESC ExtPropertyFeatureDescriptor =
{
//----------Header Section--------------
sizeof(ExtPropertyFeatureDescriptor), //dwLength
0x0100, //bcdVersion = 1.00
EXTENDED_PROPERTIES, //wIndex
0x0001, //wCount - 0x0001 "Property Sections" implemented in this descriptor
//----------Property Section 1----------
132, //dwSize - 132 bytes in this Property Section
0x00000001, //dwPropertyDataType (Unicode string)
40, //wPropertyNameLength - 40 bytes in the bPropertyName field
{'D','e','v','i','c','e','I','n','t','e','r','f','a','c','e','G','U','I','D', 0x0000}, //bPropertyName - "DeviceInterfaceGUID"
78, //dwPropertyDataLength - 78 bytes in the bPropertyData field (GUID value in UNICODE formatted string, with braces and dashes)
//The below value is the Device Interface GUID (a 128-bit long "globally unique identifier")
//Please modify the GUID value in your application before moving to production.
//When you change the GUID, you must also change the PC application software
//that connects to this device, as the software looks for the device based on
//VID, PID, and GUID. All three values in the PC application must match
//the values in this firmware.
//The GUID value can be a randomly generated 128-bit hexadecimal number,
//formatted like the below value. The actual value is not important,
//so long as it is almost certain to be globally unique, and matches the
//PC software that communicates with this firmware.
{'{','5','8','d','0','7','2','1','0','-','2','7','c','1','-','1','1','d','d','-','b','d','0','b','-','0','8','0','0','2','0','0','c','9','a','6','6','}',0x0000} //bPropertyData - this is the actual GUID value. Make sure this matches the PC application code trying to connect to the device.
};
I wish I could be more help. We ended up making a major change to this project that has pushed it out and I have been focusing on hardware and postponed looking into this as I had a workaround using a custom .inf file and disabling driver signature enforcement for now. I was hoping maybe possibly it would be added to Harmony by the time I got back to it. Now we've ended up switching to another CPU because of RAM and ADC limitations. I did however receive the below response in my ticket that may be helpful. It seems Microchip added the Microsoft string descriptors to MLA but not to Harmony! I posted the MLA descriptors below as well for reference.
Sorry I could not be more help!
Martin
Microchip Ticket Support:
The "MLA" (Microchip Library of Applications) which provides software stacks on USB, TCP/IP, Graphics etc. for 8 & 16-bit PICs (so the PIC32 is not included anymore, since it uses Harmony now), also has an example for WinUSB supporting the new feature you described.
In case you wish to see how it's been implemented, you could do this:
> Download & install the MLA (latest version!), or at least the USB Framework & examples from its installation menu:
> Open the MPLAB X demo located by default under:
C:\microchip\mla\v2014_07_22\apps\usb\device\vendor_basic\firmware
> Look for the “IMPLEMENT_MICROSOFT_OS_DESCRIPTOR” configuration option. You can see the vendor specific descriptor in usb_descriptors.c
MLA Descriptors:
//Microsoft "OS Descriptor" - This descriptor is based on a Microsoft specific
//specification (not part of the standard USB 2.0 specs or class specs).
//Implementing this special descriptor allows WinUSB driver package installation
//to be automatic on Windows 8. For additional details, see:
//
const MS_OS_DESCRIPTOR MSOSDescriptor =
{
sizeof(MSOSDescriptor), //bLength - lenght of this descriptor in bytes
USB_DESCRIPTOR_STRING, //bDescriptorType - "string"
{'M','S','F','T','1','0','0'}, //qwSignature - special values that specifies the OS descriptor spec version that this firmware implements
GET_MS_DESCRIPTOR, //bMS_VendorCode - defines the "GET_MS_DESCRIPTOR" bRequest literal value
0x00 //bPad - always 0x00
};
//Extended Compat ID OS Feature Descriptor
const MS_COMPAT_ID_FEATURE_DESC CompatIDFeatureDescriptor =
{
//----------Header Section--------------
sizeof(CompatIDFeatureDescriptor), //dwLength
0x0100, //bcdVersion = 1.00
EXTENDED_COMPAT_ID, //wIndex
0x01, //bCount - 0x01 "Function Section(s)" implemented in this descriptor
{0,0,0,0,0,0,0}, //Reserved[7]
//----------Function Section 1----------
0x00, //bFirstInterfaceNumber: the WinUSB interface in this firmware is interface #0
0x01, //Reserved - fill this reserved byte with 0x01 according to documentation
{'W','I','N','U','S','B',0x00,0x00},//compatID - "WINUSB" (with two null terminators to fill all 8 bytes)
{0,0,0,0,0,0,0,0}, //subCompatID - eight bytes of 0
{0,0,0,0,0,0} //Reserved
};
//Extended Properties OS Feature Descriptor
const MS_EXT_PROPERTY_FEATURE_DESC ExtPropertyFeatureDescriptor =
{
//----------Header Section--------------
sizeof(ExtPropertyFeatureDescriptor), //dwLength
0x0100, //bcdVersion = 1.00
EXTENDED_PROPERTIES, //wIndex
0x0001, //wCount - 0x0001 "Property Sections" implemented in this descriptor
//----------Property Section 1----------
132, //dwSize - 132 bytes in this Property Section
0x00000001, //dwPropertyDataType (Unicode string)
40, //wPropertyNameLength - 40 bytes in the bPropertyName field
{'D','e','v','i','c','e','I','n','t','e','r','f','a','c','e','G','U','I','D', 0x0000}, //bPropertyName - "DeviceInterfaceGUID"
78, //dwPropertyDataLength - 78 bytes in the bPropertyData field (GUID value in UNICODE formatted string, with braces and dashes)
//The below value is the Device Interface GUID (a 128-bit long "globally unique identifier")
//Please modify the GUID value in your application before moving to production.
//When you change the GUID, you must also change the PC application software
//that connects to this device, as the software looks for the device based on
//VID, PID, and GUID. All three values in the PC application must match
//the values in this firmware.
//The GUID value can be a randomly generated 128-bit hexadecimal number,
//formatted like the below value. The actual value is not important,
//so long as it is almost certain to be globally unique, and matches the
//PC software that communicates with this firmware.
{'{','5','8','d','0','7','2','1','0','-','2','7','c','1','-','1','1','d','d','-','b','d','0','b','-','0','8','0','0','2','0','0','c','9','a','6','6','}',0x0000} //bPropertyData - this is the actual GUID value. Make sure this matches the PC application code trying to connect to the device.
};
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Tez)
The upcoming v1.04 release of MPLAB Harmony support an advanced string descriptor table format. This format allow the string index to be specified in the string descriptor table. You will be able to easily support the 0xEE string index.
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (MaxVA)
Thanks Martin Franke and Tez for your help. When will Harmony 1.04 be released? Depending on the release date I can delay the WINUSB part of my project and work on the application itself.
As a suggestion for Harmony 1.04 USB stack, a example using this enumeration method would be of great help and a plus on the framework USB utility since it is the easiest enumeration method already completely supported for windows 8 and latter and can be supported in windows 7 using a microsoft-provided update.
As a suggestion for Harmony 1.04 USB stack, a example using this enumeration method would be of great help and a plus on the framework USB utility since it is the easiest enumeration method already completely supported for windows 8 and latter and can be supported in windows 7 using a microsoft-provided update.
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Tez)
The v1.04 release of Harmony should be out any time now. The USB Device stack documentation in this release contains a section called Advanced String Descriptor Table. This section describes the new string descriptor table format and shows an example usage. Note that all string descriptor table entry data structures should be packed.
↧
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (MaxVA)
Tez
The v1.04 release of Harmony should be out any time now. The USB Device stack documentation in this release contains a section called Advanced String Descriptor Table. This section describes the new string descriptor table format and shows an example usage. Note that all string descriptor table entry data structures should be packed.
Hello Tez,
First of all thanks for your help, I had to switch to another task for a few days and today I returned to my "WinUSB" project and after reading your comment I updated MPLAB X IDE and Harmony. So now I am already using Harmony 1.04.01 and MPLAB X IDE v3.00.02 beta (required for that Harmony version). I already found a couple of bugs and wanted you to know for a quick fix:
1- When you write in the "Product String" text dialog of the Harmony USB configurator it is not correctly ported to the "system_init.c" product string descriptor. For example, if I write "HELLO" in that text field after the code generation we got this:
sd002 =
{
2, // Index of this string descriptor is 2.
0x0409, // Language ID of this string descriptor is 0x0409 (English)
sizeof(sd002)-sizeof(sd002.stringIndex)-sizeof(sd002.languageID),
USB_DESCRIPTOR_STRING,
HELLO
};
The correct code generation is:
sd002 =
{
2, // Index of this string descriptor is 2.
0x0409, // Language ID of this string descriptor is 0x0409 (English)
sizeof(sd002)-sizeof(sd002.stringIndex)-sizeof(sd002.languageID),
USB_DESCRIPTOR_STRING,
{'H','E','L','L','O'}
};
2- Even in this new version of MPLAB X IDE and Harmony (since today I was using MPLAB X IDE 2.25 and Harmony 1.03.01) I still have the GPIO "first" configuration error I described on the "Some difficulties in usage of Harmony Configurator (1.0.3)" post of this forum (I tried several times to insert the URL here but it dissappears). I already checked the changes on "sys_ports_static.c" but I still have the same wrong behaviour on the PIC32 USB STARTER KIT III. I am still thinking that the problem is "PLIB_PORTS_Toggle" since replacing it with "PLIB_PORTS_Write" works fine.
Waiting for any notice, thanks!
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (Tez)
Hello Max
Regarding the first issue, when you are entering the text in MHC, try typing "{'H','E','L','L','O'}". I think the documentation may not have been clear on this. The documentation will be updated. Please ensure that these structures are packed (I think MHC already generates code as such).
On issue 2, I will search your other thread.
Regards
Regarding the first issue, when you are entering the text in MHC, try typing "{'H','E','L','L','O'}". I think the documentation may not have been clear on this. The documentation will be updated. Please ensure that these structures are packed (I think MHC already generates code as such).
On issue 2, I will search your other thread.
Regards
↧
Re: USB String Descriptor at string index of 0xEE for Microsoft WinUSB driver (MaxVA)
Tez
Hello Max
Regarding the first issue, when you are entering the text in MHC, try typing "{'H','E','L','L','O'}". I think the documentation may not have been clear on this. The documentation will be updated. Please ensure that these structures are packed (I think MHC already generates code as such).
On issue 2, I will search your other thread.
Regards
Hello Tez,
Regarding the advanced string descriptor table, it is not working for me with string index 0xEE. I use this Harmony configuration:
Now, in "system_init.c":
/*******************************************
* OS string descriptor (WinUSB, index 238)
*******************************************/
const struct __attribute__ ((packed))
{
uint8_t stringIndex; //Index of the string descriptor
uint16_t languageID ; // Language ID of this string.
uint8_t bLength; // Size of this descriptor in bytes
uint8_t bDscType; // STRING descriptor type
uint16_t string[8]; // String
}
sd238 =
{
238, // Index of this string descriptor is 238.
0x0409, // Language ID of this string descriptor is 0x0409 (English)
sizeof(sd238)-sizeof(sd238.stringIndex)-sizeof(sd238.languageID),
USB_DESCRIPTOR_STRING,
{'M','S','F','T','1','0','0',1}
};
/***************************************
* Array of string descriptors
***************************************/
USB_DEVICE_STRING_DESCRIPTORS_TABLE stringDescriptors[4]=
{
(const uint8_t *const)&sd000,
(const uint8_t *const)&sd001,
(const uint8_t *const)&sd002,
(const uint8_t *const)&sd238
};
/*******************************************
* USB Device Layer Master Descriptor Table
*******************************************/
const USB_DEVICE_MASTER_DESCRIPTOR usbMasterDescriptor =
{
&deviceDescriptor, /* Full speed descriptor */
1, /* Total number of full speed configurations available */
fullSpeedConfigDescSet, /* Pointer to array of full speed configurations descriptors*/
NULL,
0,
NULL,
4, // Total number of string descriptors available
stringDescriptors, // Pointer to array of string descriptors.
NULL, //Full speed device qualifier
NULL,
NULL
};
Calling it "sd238" its just because of the "0xEE" index. Then I initialize the USB in "app.c" and register a callback with a breakpoint on a USB_DEVICE_EVENT_CONTROL_TRANSFER_SETUP_REQUEST of the WINUSB type but it is never reached (and the enumeration fails). Debugging I ended on this function in "usb_device.c":
uint16_t _USB_DEVICE_GetStringDescriptorRequestProcessAdvanced
(
USB_DEVICE_MASTER_DESCRIPTOR * ptrMasterDescTable,
USB_SETUP_PACKET * setupPkt,
void** pDescriptorString
)
{
uint8_t* stringDesc;
uint16_t langID;
uint8_t stringIndexRequested;
uint16_t DescriptorStringSize = 0;
uint8_t count;
uint8_t stringIndex;
/* Get the string descriptor index from setup packet*/
stringIndexRequested = setupPkt->bDscIndex;
if (stringIndexRequested == 0)
{
/* Get pointer to String Descriptor */
stringDesc = (uint8_t*)&(ptrMasterDescTable->stringDescriptorTable[0][3] );
*pDescriptorString = (uint8_t *)stringDesc;
/* Get Size of the String descriptor. Size is always the First
element in the String descriptor structure */
DescriptorStringSize = stringDesc[0];
}
//----------------
else if (stringIndexRequested == 0xEE)
{
/* Get pointer to String Descriptor */
stringDesc = (uint8_t*)&(ptrMasterDescTable->stringDescriptorTable[3][3] );
*pDescriptorString = (uint8_t *)stringDesc;
/* Get Size of the String descriptor. Size is always the First
element in the String descriptor structure */
DescriptorStringSize = stringDesc[0];
}
//-----------------
else
{
for (count = 1; count < ptrMasterDescTable->stringDescCount; count++ )
{
/* Get the string index from the String Descriptor. String Index
is always the third element in the String Descriptor */
stringIndex = ptrMasterDescTable->stringDescriptorTable[count][0];
/* Get Language ID from the string descriptor. Language ID is
always the Fourth element in the String Descriptor */
langID = ((uint16_t)ptrMasterDescTable->stringDescriptorTable[count][2]<<8)
|ptrMasterDescTable->stringDescriptorTable[count][1];
/* Check if the Requested String Index and Language ID matches with
the values retrieved from String Descriptor */
if ((stringIndex == stringIndexRequested)
&& (langID == setupPkt->wLangID))
{
/* The Requested String Descriptor and Language was found.
Get pointer to String Descriptor */
stringDesc = (uint8_t*)&( ptrMasterDescTable->stringDescriptorTable[count][3] );
*pDescriptorString = (uint8_t *)stringDesc;
/* Get Size of the String descriptor. Size is always the First
element in the String descriptor structure */
DescriptorStringSize = stringDesc[0];
break;
}
}
}
/* Return String descriptor size. USB device layer would stall the request
if the requested string descriptor was not found. If requested string
was not found the DescriptorStringSize would be zero and pDescriptorString
would be NULL. */
return DescriptorStringSize;
}
The code between "//-------------" is my modification and it works, the WINUSB string descriptor was sent since my program reach the next WINUSB transaction at the breakpoint I mentioned before. Without the modification somehow the "ptrMasterDescTable->stringDescCount" on the for loop gets corrupted and does not work.
Am I doing something wrong with that string descriptor on "system_init.c"? Thanks!
↧