Question regarding clock generation and distribution of the T3.6

Status
Not open for further replies.

Theremingenieur

Senior Member+
I've tried to understand the K66 reference manual and to make the link with what happens in the mk20dx128.c file, but I don't get it sorted...

Running the T3.6 at 180MHz would normally not allow USB operation since there is no fitting clock divider. That's why a 48MHz helper clock is used to generate the USB clock. So far, so good.

My problem seems a little more complex: I'd like to run the T3.6 as quick as possible without over clocking (180MHz) and have a high PDB clock which is not too far beyond the specs, but it would have to be a multiple of 192kHz, for example 57.6MHz or 48MHz, which would be acceptable in case it was easy to re_route IRC48M to the PDB0 while the other peripherals (FTMs etc) would ideally run with a bus clock around 60MHz.

Paul, Frank, any suggestion from the clock gurus?
 
I've tried to understand the K66 reference manual and to make the link with what happens in the mk20dx128.c file, but I don't get it sorted...

Running the T3.6 at 180MHz would normally not allow USB operation since there is no fitting clock divider. That's why a 48MHz helper clock is used to generate the USB clock. So far, so good.

My problem seems a little more complex: I'd like to run the T3.6 as quick as possible without over clocking (180MHz) and have a high PDB clock which is not too far beyond the specs, but it would have to be a multiple of 192kHz, for example 57.6MHz or 48MHz, which would be acceptable in case it was easy to re_route IRC48M to the PDB0 while the other peripherals (FTMs etc) would ideally run with a bus clock around 60MHz.

Paul, Frank, any suggestion from the clock gurus?

Hi,

with 144 or 192 MHz you can get a 48MHz BUS-Clock. 192MHz is not much above 180, and i'd say it is save to use it. T3.2 is rated for 72Mhz and we usually run it with 96Mhz.

For setting the F_BUS, add a define F_BUS=48000000 to the GCC-Commandline - either with editing boards.txt, which, unfortunately, would result in changing it for every Sketch, or, better try my "defs.h" ( https://forum.pjrc.com/threads/38533-HOWTO-Store-Projects-settings-(like-F_CPU-USB-Keyboard-layout) )
- in this case, create in file "defs.h" in your sketch-directory with one line:
Code:
-DF_BUS=48000000
I'm using a simple batch and windows-ports of diff/patch from linux to patch my teensyduino, it takes only a second after updating teensyduino.

RE: the IRC48M: I have to look at the datasheet first.

EDIT:
Ooops, 48MHZ F_BUS is default for 192+144MHz, so nothing to do.. forget "-DF_BUS=48000000" :)
 
Last edited:
I agree, 192 & 144 MHz are your best options.

IRC48M has only limited uses, since it's not synchronous to the system clock. Some peripherals can use it, but only because they have special circuitry to allow data to sync between different clock domains. Most of the peripherals simply can't run from IRC48M.
 
It's not driven by the crystal, too. It is an on-chip oscillator - It can sync to USB if a USB cable is connected, but it will be not very exact, if not.
 
Thank you all for these thoughts. I think I'll go with 192 & 48MHz although I found the idea appealing to keep F_BUS around 60MHz to have a better resolution when doing FTM input capture while still being able to run the PDB+DAC with a 192kSamples/s rate. Or I keep the 180 & 60MHz concept and I accept a slightly different sample rate.
 
Status
Not open for further replies.
Back
Top