K64 USB Stuck On Attaching (USB_KHCI_EVENT_SOF_TOK Interrupt constantly going off and not handled)

[dave_harmonjr]

I am working on a K64 project where the processor is directly connected to a USB Hub. I am following the code from the frdmk64f_host_hid_generic_freertos SDK example. I am able to initialize the USB and USB tasks. It gets a "USB_KHCI_EVENT_ATTACH" event and then the IRQ handler for USB gets immediately spammed with USB_KHCI_EVENT_SOF_TOK interrupts and then ends up locking up the OSA_EventSet function because it maxes out at 10 events in the queue then blocks. Any idea why this might be and how I might handle this?

[dave_harmonjr]

Looking at the code for this I am not sure how this makes much sense to me. It appears that in the attach code there is a 100ms delay

And if you look at how the delay is implemented in the code it counts how many SOF's are received because you get 1 every 1ms so this should count to 100 SOFs to perform the 100ms delay.

But while it is in this loop the events are no longer being processed since the attach function is run from the task that is receiving the SOF events, thus after it counts to 10 SOF's the Event Set throws a failure because the event queue is limited to 10 events. Trying to figure out how the demo works, but my project does not.

[dave_harmonjr]

uint32_t USB_HostHubGetTotalThinkTime(usb_host_handle hostHandle, uint8_t parentHubNo)
{
    usb_host_hub_instance_t *hubInstance;
    uint32_t deviceAddress           = 0U;
    usb_host_hub_global_t *hubGlobal = USB_HostHubGetHubList(hostHandle);
    if (hubGlobal == NULL)
    {
        return 0U;
    }
    hubInstance = hubGlobal->hubList;

    /* get parentHubNo's hub instance handle */
    while (hubInstance != NULL)
    {
        (void)USB_HostHelperGetPeripheralInformation(hubInstance->deviceHandle, (uint32_t)kUSB_HostGetDeviceAddress,
                                                     &deviceAddress);
        if (parentHubNo == deviceAddress)
        {
            break;
        }
        hubInstance = hubInstance->next;
    }
    if (hubInstance != NULL)
    {
        return hubInstance->totalThinktime;
    }
    return 0;
}

I upped the queue length in the FreeRTOSConfig.h file to 105 so it would process the SOF's after it did the 100ms delay which seemed to work as now what happens is I get an attach event, reset device event, then a hub attached event and then it hardfaults at the function I posted above. I stepped through it and it seems that the hubInstance->next never equals null even though there is only 1 hub. So it ends trying to assign a garbage pointer to  hubInstace and then hardfaults there. Trying to find where hubInstance->next should be assigned to null because it never does as far as I can tell.

I also found that when you create a new project with the latest SDK that the examples don't seem to match the version of FreeRTOS that the new projects have. I ran a file comparison on the FreeRTOSConfig.h and found some differences that I altered to make match.

[dave_harmonjr]

I ended up realizing the issue is that for some reason the USB_HostHubGetTotalThinkTime function thinks the devices parentHubNo is 0 and the device address is 1 so it loops through garbage pointers causing the hardfault. I tried hardcoding the parentHubNo to 1 and it worked through it. Still don't understand why this isn't being set correctly and crashing.

[dave_harmonjr]

Decided to go back to this and see if I can logically figure out why this driver appears to be bugged. I am running under the assumption that this is some kind of misconfiguration and not a bug, but I am not finding or getting any help with this.

To reiterate what is going on. I have a K64 trying to be a USB Host that connects directly to a USB Hub Chip. When it enumerates it runs the function USB_HostHubGetTotalThinkTime then hardfaults after cycling through the while loop in there because the parentHubNo never matches the device address. After thinking about this more I am not sure how this function makes sense for my configuration. The parentHubNo appears to be the Host (K64) and the device is the USB Hub. The parentHubNo comes from the deviceInstaces->HubNumber which is 0 because it's tied directly to the host. Okay that makes sense to me sort of. But the USB Hubs device address is 1 so I am unsure how this function would ever work because deviceAddresses are never 0?

[dave_harmonjr]

Found out that there is an SDK for the Tower K64F and tried some of those example programs and those worked no issue. So there appears to be some compatibility issue with the package used on the Freedom board vs the Tower Board for my use case.