Kinetis USB stack question

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Kinetis USB stack question

Jump to solution
847 Views
izmile
Contributor III

Hi,

I am using the Freescale USB stack v4.1.1 with K60DN256Z processor. I could get the USB hid device emumerated properly. However, when I do SET REPORT, the (proper) data reaches the controller only if I send the SET REPORT again. I other words, it is like the data is double buffered internally and it gets flushed only on the next SET REPORT command.

I browsed through the usb code and found the following code an usb_dci.c, function: USB_DCI_OnDeviceSetupPacket

           if((pSDP.bmRequestType == USB_DCI_SET_REQUEST_ITF)||

               (pSDP.bmRequestType == USB_DCI_SET_REQUEST_EP))

            {

                    event.setup = TRUE;

                (void)USB_Device_Call_Service(EpNum, &event);

                if(pSDP.wLength > 0)

                {

                        event.setup = FALSE;

                        (void)USB_Device_Call_Service(EpNum, &event);

                }

            }

This piece of code is executed when there is a SET REPORT command. As you see, the first time USB_Device_Call_Service is called with event.setup = TRUE. This will process the setup packet from the host. Then the services schedules the next OUT transaction to be processed and it returns back. Once the service returns, it is called again with event.setup = FALSE..(since pSDP.wLength will be more than 0). Here is where I am lost... why is the service called again without waiting for the OUT transaction to be processed? 

I think the behaviour I see seems to be happening because of this. Is there something I am missing to make the USB stack working properly? Any pointer would be of great help.

BTW, my report size is 64 bytes long and I have to change the size of ext_req_to_host buffer (in usb_framework.c) to 64+8 bytes long..

Thanks,

-Ismail

Labels (1)
0 Kudos
1 Solution
407 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi ,

Are you referring to the PE example in "C:\Freescale\Freescale USB Stack v4.1.1\ProcessorExpert\Examples\Device\HID\USB_HID_MOUSE_DEVICE_K60_PEx"? Actually when "event.setup = FALSE", the "static void USB_Control_Service(PTR_USB_DEV_EVENT_STRUCT event)" handles as below:

1.PNG.png

I think that is where the stack handles the following OUT transaction.

Hope that helps,

B.R

Kan

View solution in original post

0 Kudos
3 Replies
408 Views
Kan_Li
NXP TechSupport
NXP TechSupport

Hi ,

Are you referring to the PE example in "C:\Freescale\Freescale USB Stack v4.1.1\ProcessorExpert\Examples\Device\HID\USB_HID_MOUSE_DEVICE_K60_PEx"? Actually when "event.setup = FALSE", the "static void USB_Control_Service(PTR_USB_DEV_EVENT_STRUCT event)" handles as below:

1.PNG.png

I think that is where the stack handles the following OUT transaction.

Hope that helps,

B.R

Kan

0 Kudos
407 Views
izmile
Contributor III

I have made the HID reports work by adding a delay loop before the OUT transaction processing. Following is the code modification that I did in usb_dci.c, function : USB_DCI_OnDeviceSetupPacket

        default:

            if((pSDP.bmRequestType == USB_DCI_SET_REQUEST_ITF)||

               (pSDP.bmRequestType == USB_DCI_SET_REQUEST_EP))

            {

                    event.setup = TRUE;

                (void)USB_Device_Call_Service(EpNum, &event);

                if(pSDP.wLength > 0)

                {

               volatile uint32_t delay = 0xFFFF;  // Added delay loop : wait until USB peripheral has received the OUT packet

                while(delay--);

              

                        event.setup = FALSE;

                        (void)USB_Device_Call_Service(EpNum, &event);

                }

            }

Although the HID reports work as expected, this is not a clean solution. I wonder, how this code worked for others. I am sure there are many people out there who would have implemented HID interface.

Is there a better way of doing this? I would greatly appreciate any help..

Thanks,

-Ismail

0 Kudos
407 Views
izmile
Contributor III

Hello Kan,

Thanks for your reply.

Yes, you are right that the OUT transaction will be handled by the second "else if" block that you highlighted. However, note that the second "else if" condition will be true immediately. The processor will call the g_other_req_callback even if the host did not send the OUT packet. I was expecting some sort of blocking (or interrupt mechanism) that would wait unit the OUT packet has reached the processor.

I am sure, I am missing something in the code.. I would be happy if someone points it out.

Thanks,

-Ismail

0 Kudos