USB Host Stack and K20 TWR/FRDM

[FarhanH]

Does anyone know if there are any issues with the PE USB Host stack and the K20 boards? I didn't see any examples so I created a new one and incorporated the source from the examples. I have found that the USB interrupt doesn't seem to work. When you plug in or remove a device the ISR routine for PE USB isn't called and non of the interrupt registers show anything.

When I use the non-PE files/project, the programs run fine. I checked the NVIC and USB0 settings between the PE and non-PE versions and they are fine. All the correct interrupts are enabled, the USB interrupt enable registers are correct as well. The Vectors file layout pretty closely matches the non-PE version.

Any ideas? I would prefer to use PE if possible.

Thanks!

[arielyegier]

Hello! I'm having the same issue. Could you fix it?

Regards,

Ariel

[marcbunyard]

I am having trouble with the USB stack also.  I'm on the TWR_K20D72M using PE and MQX Lite.  I did find code that got me pretty far in the examples that came with CodeWarrior 10.4 =>\CW MCU v10.4\MCU\CodeWarrior_Examples\Processor_Expert\Kinetis\TWR-K20D72M\USB_MS_Device.

I am running as a device only, and the problem I'm having is when the Host performs GetDeviceDescriptor, the request is answered, but the data sent is not the Device Descriptor data.  It's garbage from an erroneous pointer.  When I run without MQXLite, it enumerates and performs correctly.

[FarhanH]

Ah, yeah, the PE device drivers were okay when I tried them. I am using CW 10.3. Have you tried increasing the stack/heap size in PE? I was having some problems with the PE device stack before and increasing it to 600-1000 seemed to fix it.

I still have a problem with the PE USB Host stack since I can't get it to even trigger the USB interrupts (even though other peripheral interrupts work fine).

[marcbunyard]

Yes.  I just increased the stack size to 1024, and now I think I'm up and running.  I am running in device mode, and I wasn't getting the attach interrupt event because I didn't have DP Pullup Enabled and set to USBX_Internal_DP_PU.  I don't think the host side would want this, but maybe the host isn't seeing the correct voltages on DP and DM, and therefore not generating the interrupt?

[FarhanH]

It's possible. There has to be some minor difference in the setup between the PE and non-PE versions of the stack since the non-PE works fine. The KHCI loop code and all that looks alright as well. I will definitely check out the pullup.

[BlackNight]

Hi,

attached is an example of USB MSD Host with Processor Expert using the FSL USB Stack V4.1.1 (slightly modified) which works well on my FRDM-K20D50M board.

More details and links to the component sources on GitHub is provided here:

USB MSD Host for the FRDM-K20D50M Board | MCU on Eclipse

I hope this is useful.

[BlackNight]

Just in case: as that zip file with the project is from 2013, I have added to this reply the project and files for CodeWarrior for MCU10.6.

Erich

[vittorio-castel]

Hi Erich,

sorry for bothering you, but I can't find any other source for examples or documentation.

I'd like to know if it is possible to use your FSL USB stack with FRDM-K20D50M and MQX-Lite instead of Free RTOS.

I already tried your MSD-Host example with Free-RTOS and worked perfectly after adding some more stack (in shell.c, function SHELL_init, I changed +300 to +500).

In a KDS project, If I try to add both the MQX-Lite and the FSL_USB_Stack components I get a long list of compile errors.

Should I use the bare-metal version of the USB stack?

Thanks in advance for the suggestions you may give me.

Vittorio

[BlackNight]

The problem with MQX is that it wants to take ownership of the vector table, while other real time operating system take a much less intrusive approach (e.g. FreeRTOS). The FSL USB Stack itself has no dependency on the RTOS, except that in my implementation I'm using the thread save FreeRTOS malloc() instead of the non-thread safe library one (used by MQXLite).

Be free to use the bare metal version of the USB stack. But I'm wondering why you need MQXLite? Would bare metal or FreeRTOS not do what you need.

For MQX, you pretty much need the drivers and stack for MQX, while with an RTOS like FreeRTOS you can use any kind of drivers (either made for an RTOS or not). It is basically a design decision to take.

As for the Shell stack: yes, you need to give it enough stack, depending on what else you are using, and counting in the interrupt stack size.

I hope that helps,

Erich

[vittorio-castel]

Hi Erich,

MQX lite has been requested in the specifications for the project I have been involved in.

I am a newbie with this platform so I am gradually learning-by-example and studying the documentation I have found till now.

For this reason I was trying to see if I can proceed following the project directives avoiding to hit the head against the wall for a long time.

Your reply let me understand better.

Thanks a lot again.

Cheers,

Vittorio

[FarhanH]

Hi Erich,

Thanks for the code link. Do you know why the stock USB stack PE component would have an issue with the K20 board(s)? I couldn't figure out why the interrupt wasn't firing. I am still running 10.3 but have installed the new USB stack V4.1.1

[BlackNight]

Hi Farhan,

If the interrupt is not firing, then either the global interrupts are disabled, or the USB interrupts are not enabled. And yes, I think both the USB stack 4.1.1 and the Processor Expert components in it have issues: that example which is provided with the stack did not work for me. Additionally it was very hard to separate the USB stack from the application code to have it applicable and easy portable to other configurations or other targets. That's why I have crated the Processor Expert component wrapper. So just that you know: that component right now uses the FreeRTOS thread-safe memory allocation. I had not had the time to change that. Anyway, all my USB applications are using FreeRTOS, so that works perfectly for me. If you want to have it bare metal, let me know and I probably could spend the time to make that change.