KL24 internal clock and USB?

[cmason]

Should I expect USB target to be functional on a KL24 with the internal reference clock enabled?

I'm trying to port some code that's working on a MK20 to the KL24.  I've made a number of obvious adjustments to the code necessary to get it running (in particular switching bitbanding to BME) and it seems to be correctly ported; I'm not seeing any faults, etc.  The code is from the open source McHck project, with it's USB stack.

In both cases, we're using the internal reference clock and FLL.  In the case of the MK20 this is working fine; the device enumerates and communicates flawlessly.

When I try basically the same code on the KL24 again with the internal clock, the device enumerates, and often connects but immediately disconnects.  Apple's USB Prober reports a number of errors including overruns and stalls.  I can post logs if it would be helpful.

When I enable error interrupts, I see a number of errors:

(gdb) p USB0.errstat

$1 = {{raw = 139 '\213', {{<No data fields>}, piderr = 1 '\001',

      crc5eof = 1 '\001', crc16 = 0 '\000', dfn8 = 1 '\001',

      btoerr = 0 '\000', dmaerr = 0 '\000', _rsvd0 = 0 '\000',

      btserr = 1 '\001'}}}

The KL24 and MK20 are on different board layouts, so it's possible that this is a layout related issue.  If I get confirmation that this should work with the internal oscillator, I'll dig into the layout possibilities.

I had expected these devices to be similar enough for this to not be an issue.

Thanks,

-c

[kai_liu]

Actually I have raised same questions before I going to KL25Z. But FSL teams say not recommendations. Personally I think FSL should consider IRC for USB in future release, since Microchip, Crypress have done that feature.

It is interesting to know MK20 works on IRC. Amazing.

Do you run an open source project on MK20?

[cmason]

Ok, I'll make a new layout with space for an external crystal.

I'm wondering if adjusting the trim value in MCG_C3 might help.  I understand that the part comes programmed with an adjusted value in flash.  I've unfortunately overwritten that with program code.  Is there any way to recover this?  Is it likely to differ significantly from the reset value?  I've tried adjusting it manually but I didn't see much difference in the USB behavior; however, I only tried a handful of different values. Is there a strategy to tune this with an oscilloscope?

Also can this part use a 16Mhz external crystal instead of an 8Mhz one?   The chip data sheet seems to suggest yes (Kinetis-KL24P80M48SF0.pdf page 22), but reference manual seems to suggest max 8Mhz (Kinetis-KL24P80M48SF0.pdf page 407).  Can you clarify?

I assume for USB applications I want to use a fast external oscillator not a slow one?

Thanks,

-c

PS- I'm using code from the McHck project, which is a open hardware MK20 design, with my own custom boards using the KL24.

[al_muir]

The trim value is stored in a location not accessable to the user and it is this value that is loaded after each device reset. You cannot erase this value.

The oscillator can run between 3 and 32 MHz. You can select which ever value will give you the required 96MHz PLL frequency.The USB uses the PLL as the clock source. Using a crystal greater than 8 MHz will only increase the oscillator current and provide no better USB clock. The only reason for using a value greater than 8 MHz is if you need some specific oscillator clock frequency for use by an internal peripheral (OSCERCLK). A 4MHz or 8MHz crystal will be fine.

[Kan_Li]

Hi,

Sorry for the late reply!!

This issue is due to FLL spec, so not related with the internal ref clock's precision, so trim the ref clock has no use. and it is possible to use 16MHz ext crystal, you should follow the data sheet, the RM might have some doc issue.

Hope that helps,

B.R

Kan

[Kan_Li]

Hi Christopher,

As RM states as below:

so we don't recommend using internal clock in USB application.

You might have to use an external ref instead.

Sorry for the inconvenience that has caused...

Please kindly let me know if you have any issue.

B.R

Kan

[cmason]

I captured the following two "eye" diagrams from the K20 in the McHck board:

And then the KL24 in my custom board:

I captured these on a TDS5054B in "FastAcq" mode.

I just want to confirm my belief that these additional lines in the KL24 trace are evidence towards the internal oscillator being not sufficiently accurate for USB and that I should proceed with adding a crystal.  I just want to make sure that there wasn't some other possibility given these traces.

Thanks!

-c