Problems with USB running off IRC48

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problems with USB running off IRC48

Jump to solution
2,600 Views
aune
Contributor III

Having some issues with getting the USB to work on a MK22FN512VLL12 using the IRC48 oscillator. ( Using Freescale USB Stack 4.1.1 )

I have enabled the oscillator in USB_RECOVER_INT_EN, also selected it as USB source in SIM ( USBSRC=1 and FLLPLLSEL =3). I also also measured the IRC48CLK on PTC3 when selecting CLKOUT = 7. so the clock seems to be running.

I can measure that the DP+ not gets pulled high once the register is set ( NONOTGPULLUP ), so guessing that this means that the USB module is still static, but can't understand why.

PLL and FLL are off, cpu is runnig of fast IRC ( 4MHz ). Normally operating in VLPR mode, but once USB cable is connected, I go back into RUN mode. Keeping LP bit set to disable PLL and FLL as they are not used.

0 Kudos
1 Solution
2,105 Views
aune
Contributor III

There we go!!

Connected vbus directly to VREGIN and that did the trick!

Thanks again for all the assistance, this probably would be one of the last things I would have checked, so you saved me lots of time!

Best Regards

Ove

View solution in original post

0 Kudos
14 Replies
2,105 Views
mjbcswitzerland
Specialist V

Hi

For FS USB operation on the K22 the system and core clock must be >= 20MHz.

Does this explain the problem?

You can also run the core directly from the same 48MHz IRC48M as the crystal-less USB device uses, although you may need to workaround silicon issues in the early parts. Details in the "IRC48M Workaround" section at http://www.utasker.com/kinetis/MCG.html and full code in the uTasker project.

Regards

Mark

0 Kudos
2,105 Views
aune
Contributor III

If core clock have to be 20Mhz or more it sure does, as I do not change the clock when transitioning from VLPR to RUN, so running at 4MHz core clock.

When I think about it it sounds logical, that that big a freq-difference could cause problems, been assuming that the clock have been the issue, but not that it was to slow :smileyhappy:

Where did you get this information ? Can't remeber having seen this in the datasheet ?

0 Kudos
2,105 Views
mjbcswitzerland
Specialist V

Hi

pastedImage_0.png

This is a standard requiremenet for all USB devices (not just the K22).

Unfortunately the USb stack 4.1.1 doesn't do any clock checking, whereas it is best if the compiler already warns you that something could be wrong.

When I try your configuration with the uTasker USB stack I get the message:

"fatal error C1189: #error :  system clock much be at least 20MHz to allow USB operation!"

so immediately get informed of the issue before any code builds and any time is lost.

Regards

Mark

0 Kudos
2,105 Views
aune
Contributor III

Haven't looked at that table before, but it sure explains what you are saying.

So now ( When USB cable is connected ), I transition from VLPR to RUN first, then transition back from BLPI to -> FEI to run off the FLL.

Configure the FLL to generate 48Mhz clock so feed the USB module directly MCGFLLCLK, PLLFLLSEL = 0. Core runs at 48Mhz, and bus, flash and flexbus runs on 24Mhz, USBSRC = 1 .

I have verified the speeds from PTC3. But for some reason the USB module still will not work properly, pullup will not be set for some reason!

0 Kudos
2,105 Views
mjbcswitzerland
Specialist V

Hi

Which clock source do you use for the FLL?

FLL is not suitable for USB since its jitter is too high (it will not pass certification), also the 32kHz IRC source is not accurate enough.

Either use PLL from an external crystal, the IRC48M or a dedicated 48MHz external clock on its USB clock input.

For USB device IRC48M is the most convenient choice.

Regards

Mark

0 Kudos
2,105 Views
aune
Contributor III

I use the IRC32 as FLL clock source. I found the part about jitter being to high, but the USB should still work shouldn't it ?

Also tried to use FLL to just feed the core, and the IRC48 to feed the USB ( PLLFLLSEL = 3), but still nothing...

Starting to wonder if there might be a hardware problem since nothing seems to work on my PCB, but if I load the same code on freedom board it works right away! Not exact same controller, but same series K22_100.

Or is there something I might be missing ?

If I place the USB init code as the first to run after reset, on my PCB nothing happens, on the FRDM board PC triggers on the USB cable connecting.

I'm running MK22FN512VLL12, but the freedom board is running MK22FN512VLHL12. Can't find any major differences that might explain this problem.

0 Kudos
2,105 Views
mjbcswitzerland
Specialist V

Hi

For serious work the FLL should be avoided - it can work in the lab with various poor clocks but this would only be for experimentation/fun.

HW issues with USB on the K22F120 tend to be due to the VREGIN/VOUT33 circuit - the wrong capacitor value, or simply forgetting that it is needed are typical reasons for USB not working.

Regards

Mark

0 Kudos
2,105 Views
aune
Contributor III

Will implement use of PLL right away instead of using FLL.

Right now the voltage regulator in/output is not tied to anything, I can see from the schematics on the freedomboard that there is a 0.1uF capacitor tied to it.

From the datasheet I see that the recommendation is to tie VREGIN together with VREGOUT through a 10k resistor to ground.

Could this really be the reason for this not working ? It can't be that simple :smileyhappy:

0 Kudos
2,105 Views
mjbcswitzerland
Specialist V

Hi

For PLL you "need" to use an external crystal (eg. 2MHz..16MHz) - for USB device only IRC48M is usually best.

There are various recommended circuits for the regulator, depending on where the power is supplied from and the voltage used.

However the external output capacitor is specified and without it it "will not" work correctly

pastedImage_0.png

As I noted before, this is where many new designs have an initial error.

Regards

Mark

0 Kudos
2,105 Views
aune
Contributor III

Reason for external crystall is because the unit is placed in various temperatur areas, and we've seen that internal oscillators drift to much to maintain the baudrate match against external components that do have internal crystals. Nothing really to with USB so my bad mentioning this.

We do not use the USB voltage regulator to power the system ( has own battery ), so I'll try tying it to ground and see if this does anything.

0 Kudos
2,105 Views
mjbcswitzerland
Specialist V

Hi

pastedImage_0.png

The VOUT33 is used to power the USB transceiver.

If you ground it your USB won't be able to work.

Regards

Mark

0 Kudos
2,105 Views
aune
Contributor III

Ahh.. Just found this picture in the reference manual right now, and feeling kinda stupid :smileyhappy:

Thanks for not RTFM'ing me sooner :smileyhappy: this totally explains my problems. The freedom board do have VBUS connected to the VREGIN, and mu PCB has non input here, no no wonder there is nothing happening..

Anyways, I'm sure this will solve the issue, going to try it right away and let you know.

Anyways, thanks a lot for the help

0 Kudos
2,105 Views
aune
Contributor III

I managed to get the PLL up and running with external crystal, generating PLLclk = 48Mhz, which is feed to USB through MCGPLLCLK ( PLLFLLSEL = 1).

Core runs at 48Mhz, bus, flash and flexbus runs at 24Mhz.

I have verified the frequencies on PTC3.

When I connect the USB cable the software makes transition som BLPE/VLPR -> RUN/PEE, after this is verified and done the USB starts up. But for some reason the computer will not recognize the device. If I plug into a win7 computer it said that it "failed to get device description".

But if I break the software I can see that I do get a token from the computer with device descriptor request and it the protocol stack ( Freescale 4.1.1 ) breaks at the usb_descriptor.c file where it does get the descriptor, the protocol stack flags no errors.

Any idea why the computer won't recognize it ?

0 Kudos
2,106 Views
aune
Contributor III

There we go!!

Connected vbus directly to VREGIN and that did the trick!

Thanks again for all the assistance, this probably would be one of the last things I would have checked, so you saved me lots of time!

Best Regards

Ove

0 Kudos