Code goes into the weeds when attempting second use of USB example without resetting

cancel
Showing results for 
Search instead for 
Did you mean: 

Code goes into the weeds when attempting second use of USB example without resetting

Jump to solution
85 Views
williamwolthuis
Contributor III

I am using the USB example frdmk64f_host_msd_fatfs_bm as a basis for use of a USB flash drive on a Kinetis K64 prototype device.  I've used the code both in my bootloader as well as my main program to allow the main program to be updated from a USB flash drive after using it to do an update.  The problem I am having is that when I go from the bootloader to the main program after updating it, the code seems to get lost in the weeds.  If I break the program I see that the code is at an address within the function USB0_IRQHandler in the main program.  I have made sure that my file has been closed and that the drive has been unmounted in the bootloader.  I found a function called USB_HostApplicationDeinit and tried that but it seems to get in an infinite loop.  Our board also has the ability to disable power to the USB port and I have tried that (for 100ms) with no luck.   The only thing I've been able to do to get it to work is to call NVIC_SystemReset() which goes through the bootloader a second time, sees that it has been updated so doesn't access the USB flash drive, and then successfully runs the main program.

Can anyone suggest what else I might need to be doing in order to get this to work without calling NVIC_SystemReset?

0 Kudos
1 Solution
52 Views
williamwolthuis
Contributor III

Interestingly, calling that function directly didn't fix the problem and it got hung up in some different USB code when I ran my main application.  However, as I mentioned, I was able to remove power from the USB port and by doing that and then calling the usual handler functions used by the demo:

USB_HostTaskFn(g_HostHandle);
USB_HostMsdTask(&g_MsdFatfsInstance);

I was able to indirectly call USB_HostMsdDeinit when the USB code detected that the device was detached.  This had the desired effect of allowing me to call the main code from my bootloader and successfully initializing the USB flash drive without the code going into the weeds.  So, I think I am good to go.  Thanks for your help.

By the way, I'm running SDK 2.8.2 in case that is still of any interest at this point.

View solution in original post

0 Kudos
2 Replies
61 Views
Alexis_A
NXP TechSupport
NXP TechSupport

Hello @williamwolthuis,

Can you let me know which SDK version are you using? The latest SDK (2.9.0) uses the API USB_HostMsdDeinit to deinitialize the module.

Also, I will suggest trying using the following API USB_HostMsdDeinit before calling the DeInit.

Best Regards,

Alexis Andalon

0 Kudos
53 Views
williamwolthuis
Contributor III

Interestingly, calling that function directly didn't fix the problem and it got hung up in some different USB code when I ran my main application.  However, as I mentioned, I was able to remove power from the USB port and by doing that and then calling the usual handler functions used by the demo:

USB_HostTaskFn(g_HostHandle);
USB_HostMsdTask(&g_MsdFatfsInstance);

I was able to indirectly call USB_HostMsdDeinit when the USB code detected that the device was detached.  This had the desired effect of allowing me to call the main code from my bootloader and successfully initializing the USB flash drive without the code going into the weeds.  So, I think I am good to go.  Thanks for your help.

By the way, I'm running SDK 2.8.2 in case that is still of any interest at this point.

View solution in original post

0 Kudos