{with apologies if this is a double post...it seems as if the first post didn't make it into "MQX Software Solutions"?}
I have a USB device application (K60) based on the USB Audio class in MQX 4.0.2.
The application works (as best as I can tell), but I noticed something odd about the status reported by Linux. The device is bus-powered, and is set this way in the descriptor, and 'lsusb' reports this correctly when looking at the descriptor bits, but, on the very last line of lsusb output, it reports "Device Status 0x0001 (Self powered)".
Digging through the class code a bit, I found that in dev_utl.c::_usb_device_get_status, when component==USB_STATUS_DEVICE, it returns usb_dev_ptr->USB_DEVICE_STATE. In _usb_device_set_status, it sets usb_dev_ptr->USB_DEVICE_STATE to the 'setting' parameters passed to it without checking to see if the device actually supports that setting. So my guess is that the host is trying to set the device to self-powered, the MQX code gleefully accepts the setting and reports it back to the host, but nevertheless my device is bus powered and is going to stay that way.
As a hack, I changed the response in _usb_device_get_status ( component==USB_STATUS_DEVICE) to return 0, and sure enough, lsusb now reports Device Status: 0x0000 (Bus Powered).
Is this a bug in the usb device software, or should I be overloading or providing a better class response somewhere else?
While admitting my ignorance of USB, the code in USB_Service_Audio_Status_Interrupt does look a bit fishy...ignoring the bits about queueing, it seems to assume that the reason for calling USB_Service_Audio_Status_Interrupt is because of USB_APP_SEND_COMPLETE, and so calls the class callback for that event. Aren't there other potential reasons for the Status Interrupt?
John
