USB not working on FRDM-K66F

[Jeff]

I can't seem to get the HS USB device to work on the FRDM-K66F board. I'm using the latest master branch from GitHub which was last updated May 6th with commit 768f306.

I enable USB and the CDC device, the code complies and I can load it but the board is stuck in a loop and seems to keep resetting. I see "Hello, world... KINETIS" repeating over and over on the UART. I was able to get debugging setup with the J-Link firmware. On line 188 in kinetis_USB_HS_Device.h when executing the fnEnterInterrupt function there is an irq_hard_fault thrown in that function (line 921 in kinetis.c). Then again on line 190 in kinetis_USB_HS_Device.h and again at line 191. I think that last one is where it gets stuck in a loop and then resets the program.

If I switch the device to run in FS mode, then there are no issue, but since there is no FS USB port on the FRDM-K66F I can't do any testing of if it actually works.

I'm not sure where to go from here to get this figured out.

[mark]

Jeff

I thought that the FRDM-K66F HS-USB was working but when I just tested it didn't work on my board either.

I didn't detect a hard fault on the first line that you mentioned - also I didn't see how it could hard fault there. However, I get the same behavior with the second hard fault and I do essentially know why it does it. It is due to the fact that the USBPHY is not supplying the clock signal to the HS USB controller - the same hard fault happens on devices with external HS USBPHY when its clock signal is not connected correctly.

There are two thing that are surprising me in this case:
1: On the FRDM-K66F there is nothing connected to the VREG0 or VREG1 inputs unless the USB host jumper (J21) is set. According to the user's manual correct VREG is one of the requirements for operation. Setting this jumper hasn't however helped yet
2. The USBPHY PLL initialisation is behaving strangely. As soon as the PLL is powered it sets its PLL locked bit, even if the crystal source hasn't been selected or the VREG is not available. This looks to be the basic issue also because the code sees that the PLL is locked but the signal is obviously not actually available - otherwise it wouldn't fail to write to the specific HS USB register.

The user's manuals is not really usable since its example code is not correct - for example, it doesn't set the USBPHY_TRIM_OVERRIDE register and so its writes will not be effective in some cases. Otherwise it is more or less the same as the code being used.

I did experiment a bit with trying to get the PLL set so that it locks only when expected (and with correct settings for this board) but didn't manage to make any progress. I have therefore requested FRDM-K66F reference project from NXP with working USB to see whether it explains anything that the user's manual doesn't.

As soon as I have news I'll post again.

Regards

Mark

[mark]

Jeff

I am sorry about the delay but I was barking up the wrong tree in this case and it was not a problem with the USBPHY clock. Since I was originally convinced of this it took me a lot of effort to finally work out what the real problem was.

Unfortunately the K26, K65 and K66 HS USB was broken when I did a change for HS K60 (only available on the >=120MHz versions) due to the fact that the wrong base address was being selected for the HS controller.

        #if defined KINETIS_K60 || defined KINETIS_K61 || defined KINETIS_K70
            #define USBHS_BASE_ADD             0x40034000                // USBHS {25}
        #else
            #define USBHS_BASE_ADD             0x400a1000                // USBHS
        #endif

becomes

        #if defined KINETIS_K26 || defined KINETIS_K65 || defined KINETIS_K66
            #define USBHS_BASE_ADD             0x400a1000                // USBHS
        #else
            #define USBHS_BASE_ADD             0x40034000                // USBHS {25}
        #endif

This correction has now been checked in for the open source and developer's versions along with another error fix that affected just the FRDM-K66F board since it uses a 12MHz crystal.

        #if _EXTERNAL_CLOCK == 24000000
        USBPHY_PLL_SIC = (USBPHY_PLL_SIC_PLL_POWER | USBPHY_PLL_SIC_PLL_ENABLE | USBPHY_PLL_SIC_PLL_BYPASS | USBPHY_PLL_SIC_PLL_DIV_SEL_24MHz); // power up PLL to run at 480MHz from 24MHz clock input
        #elif _EXTERNAL_CLOCK == 16000000
        USBPHY_PLL_SIC = (USBPHY_PLL_SIC_PLL_POWER | USBPHY_PLL_SIC_PLL_ENABLE | USBPHY_PLL_SIC_PLL_BYPASS | USBPHY_PLL_SIC_PLL_DIV_SEL_16MHz); // power up PLL to run at 480MHz from 16MHz clock input
        #elif _EXTERNAL_CLOCK == 12000000
        USBPHY_PLL_SIC = (USBPHY_PLL_SIC_PLL_POWER | USBPHY_PLL_SIC_PLL_ENABLE | USBPHY_PLL_SIC_PLL_BYPASS | USBPHY_PLL_SIC_PLL_DIV_SEL_16MHz); // power up PLL to run at 480MHz from 12MHz clock input
        #else
            #error "USB PLL requires an external reference of 12MHz, 16MHz or 24MHz!"
        #endif

Spot the 12MHz case error....This also needs to be corrected to 12MHz!

I checked USB-CDC successfully on the FRDM-K66F with these changes.


The other unexpected thing is that the PLL does indeed lock when there is no VBUS connected. On the TWR-K65 board (or K65 generally?) it doesn't. I'm not complaining since this in fact allows it to be used with and without device connection without any complications - I do wonder whether the K65 issue is in the silicon or board....?

Regards

Mark

[Jeff]

Thanks Mark! It works great now. I appreciate your help and quick response!

-Jeff K.