MCU "freezes" being busy handling USB interrupts after SetConfiguration Request

[mentair]

Hello,

I use the Freescale USB Stack v4.1.1 on a MK60FX512VLQ15 3N96B with a modified virtual com port example application.

Everything seems to work as expected, except for when an USB Set_Configuration(0) is followed by a Set_Configuration(1) request, after the application was already running correctly.

To catch the behaviour, I traced the USB ISR by letting a pin go high on entry and go low on exit of the ISR.

This is how it looks normally:

This is how it looks during the error condition (system not responding anymore at all):

It seems that the USB ISR is exited and immediately entered again.  I somehow suspect that clearing the interrupt status flags does not work.

To catch where the problem begins, I added another pin going high when USB_Class_CDC_Event is entered, and low when it is exited again.

This is how the SetConfiguration(0) looks:

And this is how it looks after the following SetConfiguration(1). After exiting the event handler, the USB Interrupt problem as shown above begins, and the status phase of the setup transaction is never executed, all IN-transfers are NACK'd:

During the Uncofigure request, the endpoints are de-initialized in USB_Class_CDC_Event. During the following SetConfiguration request, the endpoints are reinitialized like in the initial SetConfiguration Request, which got the application running in the first place.

I have no idea how this setup transfer messes up things in the ISR.

Any help appreciated.

Regards,

Martin

[isaacavila]

Hello Martin,

I could now understand the problem, I saw the USB_Strd_Req_Set_Descriptor function located at usb_framework.c file and it validates the configuration sent by the Host, if this is a valid configuration it then evaluates if this is configuration 0, if so, USB_STATE_ADDRESS is set, however, after this status is set, another set status instruction sets the USB_STATUS_CURRENT_CONFIG and this is why USB state machine is crashed. (it was thought to set the second status only if USB_STATE_CONFIG was set).

Like this is a old stack, i would like you to test if this issue is still presented in CDC example for KSDK 1.3. It has a baremetal example for CDC and has a new USB stack. I saw the USB_Strd_Req_Set_Config function and the second set_status function was removed so i hope this bug to be fixed. Can you validate it?

I hope this can help you,

Best Regards,

Isaac

----------------------------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

----------------------------------------------------------------------------------------------------------------------------------------

[isaacavila]

Hello Martin,

Sorry for late response, could you please tell me how you are defining the Configuration(1)? it would be great if you can add you modified project so i can debug it on my side using an USB sniffer.

It seems to me that callback is not being called so USB framework cannot clear interrupt flags but I would like to validate this by debugging your project

Best Regards,

Isaac

[mentair]

Hello Isaac,

thanks for taking a look at this. What do you mean by "how are you defining the Configuration(1)?"?

Also, I forgot to mention that I did debug into the Interrupt handler, and stepping through (also saving the values of the interrupt status register at several

points in the handler, especially after supposedly clearing the flags) showed that the flags were not cleared. Are you telling me that it is framework which is responsible for clearing the flags? Isn't it done directly inside the IRQ handler?

[isaacavila]

Hello Martin,

I mean what is the other configuration that you are selecting when Host sends a Set_Configuration(1).

And about second question, I will have to investigate further in USB stack in order to understand why interrupt flags are not being cleared. Could you please attach your code?

Best Regards,

Isaac

[mentair]

Hello Isaac,

I am sorry that I don't understand your question about the Configuration.  A set configuration (0) is issued by the host when it is unconfiguring the device. There is

only one configuration (1).  What essentially fails is when the host tries to "reopen" the device by configuring it again (hence the second SetConfiguration(1)), The Interrupt handler is stuck in a loop.

Can you tell me which parts of the code you need to look at? I pretty much only worked from the Virtual Com Port example as a basis, so I didn't make any adjustements in the lower layers.

Regards,

Martin

[isaacavila]

Hello Martin,

Sorry, i just thought that you were changing between two different configurations and when you switch between them problem occurred. If your USB configuration is the same as example, i think i could debug on my side using the example.

Have a nice day!

Best Regards,

Isaac