The USB PHY PLL will not lock on my custom PCA design. We are using PK65FN2M0VMI18 parts, powered at 3.3V. The VREGIN0 and VREGIN1 pins are tied together, and supplied by a bench supply at 5V so we can watch the current consumed. We are using EXTAL0 driven as an oscillator input (as opposed to crystal), driving it with a high quality (less than 1 ps rms jitter) clock generator. Typically this is set to 12 MHz, but we have also tried 16 MHz and 24 MHz. We are following requirements the May 2015 updated reference manual, with exception to using an oscillator instead of a crystal. We did not hook up USB0, so we can't even revert to using that. We have tried various register settings, and we cannot get the USB PHY PLL to lock.
It is worth noting that we can monitor the VREGOUT voltage, and we can control it correctly. We also have done an experiment with register settings and current consumption at VREGIN0 and VREGIN1:
1.) USBREGEN register (bit 31 SIM_SOPT1) cleared => 0 uA
2.) USBREGEN register (bit 31 SIM_SOPT1) set => 190 uA
3.) USBREGEN register (bit 1 SIM_SOPT2, PHY PLL Regulator Enable) cleared => 190 uA
4.) USBREGEN register (bit 1 SIM_SOPT2, PHY PLL Regulator Enable) set=> 330 uA
We have verified that the clock coming into the chip through EXTAL0 is able to run lines of code, and can be output on the CLKOUT GPIO pin and is the correct frequency.
Has anyone ever gotten USB1 working on the ES parts? We are using the example code from the reference manual and have confirmed are register settings are being written correctly.
We were able to get the PHY PLL to lock by specifying that the external oscillator was a crystal. This is shown below in Processor Expert:
This will set the EREFS field of the MCG_C2 register to a 1. This is a problem as we don't actually have a crystal and we are using the output pin as GPIO.
Is there a way to get the PHY PLL to lock without setting the EREFS field?
Hi Sam,
Thanks for pointing out the difference. I forgot to clear the EREFS bit with external oscillator clock. You are right, looks like when EREFS bit is cleared, USB PHY PLL does not lock. I will check this with design and feedback you later.
Hao
Hao,
Any progress on figuring this out?
Hi Bolton,
Sorry for late notice. I have our design check on this issue and confirmed this is an silicon issue, we will create an errata for this. As a workaround to your problem, maybe you need to pretend what connected is a crystal and that can make HS USB PHY working. I am really sorry about this.
Hao
Hao,
Are there any updates to this issue? Specifically, is it still the case that the only way to properly clock the USB HS PHY PLL is to set the input clock up as a crystal?
I looked for errata updates stating this, but I haven't found anything. We are designing our next board using a K65, and I'd like to know whether I should plan for a crystal or oscillator input at 12, 16, 24MHz.
Hi Bolton,
Have you checked if the VREGOUT is really 3.3V? I suggest try the sample code posted by Issac first and see if this works for you. Also do you have the mask set for this part? Mask set is the characters on the silicon. Is it 0N65N?
Hao
Hao,
We confirmed VREGOUT is 3.3V, and we can program it to be different voltages. The parts are marked:
PK65FN2M0
VM118
0N73J
CTZX409D
Hi Bolton,
0N73J is the 1st version of K65 engineering sample and has problems with unstable USB regulator output. Could you ask our FAE to give you samples with mask set 0N65N? I do not suggest you to try to use 0N73J.
Hao
Hao,
I now have some production parts that I plan to put on our boards. I wanted to confirm that the markings are what we want:
MK65FN2M0
VMI18
0N65N
CTAA518D
In the earlier post you had asked if the marking was 0N65N. Is that because that marking should allow USB1 to work?
-Rob
Hi Bolton,
Yes, the marking is correct. The original marking 0N73J is early version silicon which is only intended for alpha customer evaluation, it has bugs with USB regulator which are fixed with 0N65N. That's reason you would need 0N65N which is production version to have USB1 working.
Hao
Hi Rob,
I tried this minimum configuration and it works fine. I am using TWR-K65F180M so Oscillator is used but theorically it must be the same configuration for you.
It is important to connect VBUS (from USB connector) to VREG1_IN (so, i noticed that you already did it.) Please, try this simple code and let me know if PLL is still not locking.
MCG_C1 |= MCG_C1_IRCLKEN_MASK; /* 32kHz IRC enable */
OSC_CR |= OSC_CR_ERCLKEN_MASK; /* External reference clock enable */
SIM_SOPT2 |= SIM_SOPT2_USBREGEN_MASK; /* Enable USB PHY PLL regulator */
SIM_SCGC3 |= SIM_SCGC3_USBHSPHY_MASK; /* Open USB PHY clock gate */
SIM_USBPHYCTL = SIM_USBPHYCTL_USB3VOUTTRG(6); /* trim the USB regulator output to be 3.13V */
SIM_USBPHYCTL |= SIM_USBPHYCTL_USBVREGSEL_MASK; /* Selects VREG_IN1 */
USBPHY_CTRL &= ~USBPHY_CTRL_SFTRST_MASK; /* Release PHY from reset */
USBPHY_CTRL &= ~USBPHY_CTRL_CLKGATE_MASK; /* Gate UTMI Clocks */
/* Enables TRIM OVERRIDE */
USBPHY_TRIM_OVERRIDE_EN |= USBPHY_TRIM_OVERRIDE_EN_CLR_TRIM_DIV_SEL_OVERRIDE_MASK;
/* Power PHY's PLL */
USBPHY_PLL_SIC |= USBPHY_PLL_SIC_CLR_PLL_POWER_MASK;
/* In TWR-K65F180M board, Crystal is 16 MHz */
int crystal_val = 16000000;
/* Select appropiate value for PLL_DIV_SEL */
if(crystal_val == 24000000)
USBPHY_PLL_SIC &= ~USBPHY_PLL_SIC_PLL_DIV_SEL_MASK;
else if(crystal_val == 16000000)
USBPHY_PLL_SIC |= USBPHY_PLL_SIC_PLL_DIV_SEL(1);
else if(crystal_val == 12000000)
USBPHY_PLL_SIC |= USBPHY_PLL_SIC_PLL_DIV_SEL(2);
/* Wait until PLL is locked */
while (!(USBPHY_PLL_SIC & USBPHY_PLL_SIC_PLL_LOCK_MASK));
/* if program reaches this point, PLL was locked successfully */
i++;
Hope this helps,
Best Regards,
Isaac
Isaac,
Will the USB PHY PLL lock even without a cable connected to it? We are providing +5V to VREGIN_0 and VREGIN_1 from a separate supply. I am curious if the USB PHY PLL will lock even without a USB connector plugged in. My intuition tells me the USB PHY PLL locking should be completely independent of having a USB cable connected. In other words, it should lock as long as you have the correct clock frequency into EXTAL0 and you are powering VREGIN_1.
Thanks,
Rob
Bolton,
As you intuited, USB PHY PLL should lock if correct input clock frecuency is provided and VREGIN_1 is powered.
In my case, VREGIN_1 was powered by USB connector so it locked just when K65 was connected as USB Device, but in TWRK65F180M's schematic, when K65 is configured as Host, VREGIN_1 is powered from +5V_ELEVATOR and USB PHY PLL should work as well.
Regards,
Isaac
We are finally able to get the PLL to lock. The only way we are able to do this is by setting up our clock muxes to use a crystal. In other words, XTAL0 (PTA19) is an output to energize the crystal, and EXTAL0 (PTA18) is our "crystal" input. I say "crystal", because this is not what we are actually doing. We still have an oscillator driving EXTAL0, and XTAL0 is being used as a GPIO.
We would ultimately like to get away from having to set up our clock muxes for a crystal input. There was nothing that I could find in the manual dictating the use of a crystal. Do you know if this is a limitation of the part?
Hi Bolton,
I did not see such a problem when I tried to just input a 16MHz with function generator into EXTAL0 pin. USB PHY PLL can still lock and HS USB can work. Both crystal and external oscillator can work as long as the input clock frequency is either 12, 16 or 24MHz for USB PHY PLL.
Hao
Did you modify the initialization routines to specify the external oscillator is an oscillator (as opposed to a crystal)? We are able to get the PLL to lock with "crystal" register settings while still using an oscillator. I might not be understanding the setup though. Using the SDK as designed for the K65 tower board works, but changing the MCG C2 register as indicated below will keep the PLL from locking.