USB key recognized as an HUB

[arnogir]

Hello

I'm using a Kinetis K70 with MQX 4.1 (but same problem with MQX 4.2)

I'm using the USB demo for test (\demo\hvac\...)

With a key, all work fine.

With another key (also in FAT32, but not the same model/manufacturer) the demo not work:

After debug, when usb_host_driver_info_scan is called, the ouptut make the type an USB_CLAS_MASS_STORAGE when working (0x8 0050), and then  USB_CLASS_HUB (0x9 0000) when not working.

Then according ClassDriverInfoTable in usb_task.c (exemple)

- call usb_host_mass_device_event (function coded in usb_task.c of exemple) -> this function is called when plug the working key, this activate all code of the emxemple and file system is mounted...

- call usb_host_hub_device_event (function not coded in the exemple, but present in \usb\host\source\classes\hub\usb_host_hib_sm.c) -> this function is called when plug the not working key. This function not working with exemple because not generate the semaphore of the exemple (usb_taskq)...

So the questions are:

- why for some key, the recognize type is an HUB instead of Mass storage?

- Must we adapt the callack usb_host_hub_device_event to work fine (in this case, how do it) or must we look for why the USB key is recognize as an HUB???

Thank you

[bobpaddock]

Guessing here, does the device that is failing return a Device Qualifier as part of its descriptor while the working one does not?

Thesycon USB Descriptor Dumper can answer that question.

[arnogir]

Hello,

I attach the Log of USB key which work and then the USB key which not working.

I not an expert to know if there are and where are the problem...

??

[mjbcswitzerland]

Hi

I would search in the code where the decision is made to use usb_host_hub_device_event() instead of the mass-storage one, then you will know what caused the code to "believe" that it is a different device type to that expected.

Possibly the fact that there is no serial numbr in the one stick causes the USB stack confusion? According to the MSD specification each MSD device should have a unique serial number and perhaps the stack takes this too literally and decide that it can't be MSD when it is missing (?).

Regards

Mark
Kinetis for professionals: http://www.utasker.com/kinetis.html

[arnogir]

Hello

I tried to go up the code and compare between the good and bad key.

When the function usb_host_cntrl_transaction_done is called, the pointer dev_inst_ptr, which is assigned to handle->pipe_ptr->DEV_INSTANCE have the following value:

With the good key: dev_inst_ptr.dev_descriptor.bDeviceClass / SubClass / Protocol = 0x00, 0x00, 0x00 (Like in the LOG file obtained with the USB tool):

Device Qualifier Descriptor:
------------------------------
0x0A bLength
0x06 bDescriptorType
0x0200 bcdUSB
0x00 bDeviceClass  
0x00 bDeviceSubClass  
0x00 bDeviceProtocol  
0x40 bMaxPacketSize0   (64 Bytes)
0x01 bNumConfigurations
0x00 bReserved

With the bad key, these values are 0x09, 0x00, 0x00 but the Log file is Ok (like the good key):

Then due to these values, later in function usb_host_driver_info_match, the following test is TRUE:

if ((info_ptr->bDeviceSubClass == 0xFF) &&

(info_ptr->bDeviceProtocol ==

intf_ptr->bInterfaceProtocol))

{

#ifdef _HOST_DEBUG_

DEBUG_LOG_TRACE("usb_host_driver_info_match interface class, match interface protocol");

#endif

return TRUE;

}

With the good key, it is this test which is TRUE:

if ((info_ptr->bDeviceSubClass ==

intf_ptr->bInterfaceSubClass) &&

(info_ptr->bDeviceProtocol ==

intf_ptr->bInterfaceProtocol))

{

#ifdef _HOST_DEBUG_

DEBUG_LOG_TRACE("usb_host_driver_info_match interface class, match interface subclass, match interface protocol");

#endif

return TRUE;

} /* Endif */

Now, it difficult for me to know why the Class value is 09 instead of 00. It is difficult to me to understand the code executed before with the "PIPE"