USB UTMI CLK Invalid on Custom Board

[TomWilson]

Hello, 

We've just received our first prototype boards fitted with the i.mxRT 1062 MCU. The design was based closely on the RT1060_EVK. We're seeing some issues configuring the USB port and can't find the cause.

Running the evkmimxrt1060_dev_cdc_vcom_bm example on the RT1060_EVK returns expected results:

• Device Enumerates as "USB Serial Device" VCOM Port, 115200 Baud
• Successfully Prints Output to Terminal via USB
• UTMI clock register reports as valid: USBNC_USB_OTG1_PHY_CTRL_0, UTMI_CLK_VLD = 1

Running the same example firmware on our custom board:

• Device Enumerates as "SE Blank RT Family"
• UTMI clock register reports as invalid: USBNC_USB_OTG1_PHY_CTRL_0, UTMI_CLK_VLD = 0

Could anybody offer advice on what could cause the USBNC_USB_OTG1_PHY_CTRL_0, UTMI_CLK_VLD bit to read as invalid? We have checked the 24MHz crystal on our custom board, and everything seems stable. One difference between the EVK and our Custom Board is that we haven't fitted an RTC, but this shouldn't be required for USB operation. Is there potentially something about the Power-Up sequence that is preventing the UTMI clock source from initialising correctly? I should also point out that, other than USB, all other peripherals seem to be working normally. 

Many Thanks.

[gusarambula]

Hello TomWilson,

The RTC crystal should not impair the USB operation. However, it could be that your custom board is entering serial downloader mode, due to how it’s enumerated differently. How are you programming your custom board and how is the boot configuration in comparison with the EVK?

Regards,
Gustavo

[TomWilson]

Hi Gustavo, 

We're bypassing the bootloader for the moment and running over JTAG (Linking entire application to Internal RAM). We have found that the USB PLL is reporting an un-locked state and bypassed = true (see attached). With identical firmware on EVK board, PLL Lock = true, Bypass = false. Is there something about the hardware configuration.... perhaps related to power supply initialisation timing that could cause some PLLs to lock and others to fail? We know, at least, that the ARM core PLLs are running. 

Note that Hard Fault State always occurs when attempting to switch kCLOCK_PeriphMux to '0':

CLOCK_SetMux(kCLOCK_PeriphMux, 0);

Thanks, 

Tom