FRDM K64F not starting after disconnecting Ethernet PHY

cancel
Showing results for 
Search instead for 
Did you mean: 

FRDM K64F not starting after disconnecting Ethernet PHY

810 Views
paulinikula
Contributor II

I wanted to reduce power consuption of my K64F board which is quite high as is (over 100mA). After a bit of searching I found that by removing resistor R60 from the board, I can cut off power to the Ethernet PHY chip. That indeed reduced the consumption considerably, now it is only 25mA. But now the problem is that the MCU won't start running code anymore! Flash will upload without complaints, but the code execution does not start.

I suspect this is due to that the MCU uses the external 50Mhz clock supply from the Ethernet chip, which is now disabled. But shouldn't the MCU start by the internal VCO at first? I know I should be able to configure it to use the internal clock. But I have poked around the startup code files under the target folder (I'm using mbed libraries by the way) and there is not any clock setting that I can modify. I can't even find the MCG register writes that enable the external clock input in the first place. What could be the case here?

Furthermore about the MCG clock settings. Before I removed the resistor, I first tried to lower the power consumption by slowing down the clock. I found out that after reset, the clock registers are not what they are supposed to be after POR, so there must be some startup code configuring the clocks somewhere. Maybe the SDA uploader chip is doing them automatically?

10 Replies

418 Views
paulinikula
Contributor II

I did not get answer from mbed, but I managed to find the cause. In mbed-os/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/TARGET_FRDM there is file fsl_clock_config.c. In the file there is a function BOARD_BootClockRUN which does the clock source change. By commenting out CLOCK_BootToPeeMode, the MCU started running with some 20Mhz internal FLL clock.

0 Kudos

418 Views
paulinikula
Contributor II

Hi, thanks for the reply. But I'm unsure where I should put those clock register changes. I'm using ARM mbed environment, and I cannot find the startup code where it modifies the clock. I have found system_MK64F12.c file and there is the SystemInit function which "is supposed" to configure the clocks, but there is no clock setting writes, only something related to watchdog timer. If I put your code there to modify clock configuration, nothing seems to happen. I have grep searched all library folders for anything related to MCG register writes but cannot find anything useful. I'm quite puzzled, as I have worked with STM32 micros before, and they have the clock startup configuration in SystemInit which is easy to modify.

0 Kudos

418 Views
mjbcswitzerland
Specialist V

Hi Pauli


I am sure that your code will be setting up the MCG somewhere otherwise your processor would just be running a 20MHz and no Ethernet/USB would be possible.

Why not ask in the arm mbed forum since the issue is more an mdeb one that a Kinetis one?

Regards

Mark

0 Kudos

418 Views
mjbcswitzerland
Specialist V

Hi Pauli

Probably the firmware is expecting the 50MHz oscillator input from the PHY and so will wait forever for the input signal to "become valid". The code doing this will be running from the default clock.

You can use the HIRC (internal 48MHz oscillator) as PLL reference to generate the same 120MHz core frequency instead.

If your environment is not flexible you can use the following code (taken from the uTasker project for FRDM-K64F, which supports all possible configurations). You will need to be aware of a chip errata in older K64s that require the USB controller to be enabled too in order for the HIRC to work (workaround also shown below).

MCG_C7 = MCG_C7_OSCSEL_IRC48MCLK; // route the IRC48M clock to the external reference clock input (this enables IRC48M)
SIM_CLKDIV1 = (((SYSTEM_CLOCK_DIVIDE - 1) << 28) | ((BUS_CLOCK_DIVIDE - 1) << 24) | ((FLEX_CLOCK_DIVIDE - 1) << 20) | ((FLASH_CLOCK_DIVIDE - 1) << 16)); // prepare bus clock divides
MCG_C1 = (MCG_C1_IREFS | MCG_C1_CLKS_EXTERN_CLK); // switch IRC48M reference to MCGOUTCLK
while ((MCG_S & MCG_S_CLKST_MASK) != MCG_S_CLKST_EXTERN_CLK) { // wait until the new source is valid (move to FBI using IRC48M external source is complete)
    // Older K64 devices require the IRC48M to be switched on by the USB module
    if (++iIRC48M_USB_control >= IRC48M_TIMEOUT) { // if the switch-over is taking too long it means that the clock needs to be enabled in the USB controller
        POWER_UP_ATOMIC(4, USBOTG); // power up the USB controller module
        USB_CLK_RECOVER_IRC_EN = (USB_CLK_RECOVER_IRC_EN_REG_EN | USB_CLK_RECOVER_IRC_EN_IRC_EN); // the IRC48M is only usable when enabled via the USB module
    }
}
// We are presently running directly from the IRC48MCLK and have also determined whether a K64 is an older or newer device (with IRC48M independent from the USB module)
MCG_C1 = (MCG_C1_CLKS_EXTERN_CLK | MCG_C1_FRDIV_1280); // switch the external clock source also to the FLL to satisfy the PBE state requirement
MCG_C5 = ((CLOCK_DIV - 1) | MCG_C5_PLLSTEN0); // PLL remains enabled in normal stop modes
MCG_C6 = ((CLOCK_MUL - MCG_C6_VDIV0_LOWEST) | MCG_C6_PLLS); // complete PLL configuration and move to PBE
while ((MCG_S & MCG_S_PLLST) == 0) {} // loop until the PLLS clock source becomes valid
while ((MCG_S & MCG_S_LOCK) == 0) {} // loop until PLL locks
MCG_C1 = (MCG_C1_CLKS_PLL_FLL | MCG_C1_FRDIV_1024); // finally move from PBE to PEE mode - switch to PLL clock
while ((MCG_S & MCG_S_CLKST_MASK) != MCG_S_CLKST_PLL) {} // loop until the PLL clock is selected

The actual register values (if the defines are not understandable) to run at 120MHz core, 60MHz bus and 24MHz flash clock (see uTasker FRDM_K64F simulation below) are:


MCG_C7 = 0x02;
SIM_CLKDIV1 = 0x01240000;
MCG_C1 = 0x84;
// wait until the new source is valid (move to FBI using IRC48M external source is complete)
MCG_C1 = 0xb0;
MCG_C5 = 0x33;
MCG_C6 = 0x5a;
// loop until the PLLS clock source becomes valid
// loop until PLL locks
MCG_C1 = 0x28;
// loop until the PLL clock is selected


I have also attached a FRDM-K64F binary that you can load to the board in case you need to reverse engineer on the board. It has a command line interface on the VCOM UART and on the K64's USB (USB-CDC) and there are low power menus in the "administrator" menu in case you would like to check the power consumption possible in the various modes based on this clock configuration.


Regards

Mark

Kinetis: http://www.utasker.com/kinetis.html
Kinetis K64:
- http://www.utasker.com/kinetis/FRDM-K64F.html
- http://www.utasker.com/kinetis/TWR-K64F120M.html
- http://www.utasker.com/kinetis/TEENSY_3.5.html
- http://www.utasker.com/kinetis/Hexiwear-K64F.html
MCG module: http://www.utasker.com/kinetis/MCG.html
Low Leakage Modes: http://www.utasker.com/kinetis/LLWU.html


Free Open Source solution: https://github.com/uTasker/uTasker-Kinetis
Working project in 15 minutes video: https://youtu.be/K8ScSgpgQ6M

Professional Kinetis support, one-on-one training and complete fast-track project solutions: http://www.utasker.com/support.html

pastedImage_5.png

418 Views
wilb
Contributor II

Hi Mark,

Is there a convenient place on the FRDM-K64F to measure any clock derived from either the IRC48M or the 50 Mhz PHY ?

Does the change to use of IRC48M effect the OpenSDA interface ?

Thanks,

WilB

0 Kudos

418 Views
mjbcswitzerland
Specialist V

Wil

Various clocks themselves can be measured on the CLKOUT pin by enabling the pin for this function and routine the desired clock to it in SIM_SOPT2.
Otherwise you can clock the I2S with a certain clock (system, MCGPLLCLK, IRC48MCLK or OSCERCLK) and use its output signal as reference for the clock it is derived from.

There is no effect on the OpenSDA when IRC48MCLK is used.

Regards

Mark

418 Views
wilb
Contributor II

Hello Again Mark,

Thanks alot for your reply. Does the code fragment earlier in this thread reflect the state transitions described by the MCG mode State Diagram at Figure 25-14 in the K64 Sub-Family Reference Manual ? It seems that use of IRC48MCLK suggests transitions from FEI at reset to FBI, FBE, PBE mentioned in the source comments, and then PEE.

Also does a means exist to check the K64 MCU silicon revision for the need to establish USB0 Controller prior to IRC48MCLK?

Regards,

Wil B

0 Kudos

418 Views
mjbcswitzerland
Specialist V

Wil

The code respects the state transitions - there are some more practical details at:

http://www.utasker.com/kinetis/MCG.html

where the IRC48M workaround (for early silicon) is also discussed.

Below is the code in the uTasker project that distinguishes between the two since I don't believe that there is any register that informs of the correction:

    MCG_C7 = MCG_C7_OSCSEL_IRC48MCLK;                                    // route the IRC48M clock to the external reference clock input (this enables IRC48M)
    SIM_CLKDIV1 = (((SYSTEM_CLOCK_DIVIDE - 1) << 28) | ((BUS_CLOCK_DIVIDE - 1) << 24) | ((FLEX_CLOCK_DIVIDE - 1) << 20) | ((FLASH_CLOCK_DIVIDE - 1) << 16)); // prepare bus clock divides
    MCG_C1 = (MCG_C1_IREFS | MCG_C1_CLKS_EXTERN_CLK);                    // switch IRC48M reference to MCGOUTCLK
    while ((MCG_S & MCG_S_CLKST_MASK) != MCG_S_CLKST_EXTERN_CLK) {       // wait until the new source is valid (move to FBI using IRC48M external source is complete)
        #if (defined KINETIS_K64 || (defined KINETIS_K24 && (SIZE_OF_FLASH == (1024 * 1024)))) // older K64/K24 devices require the IRC48M to be switched on by the USB module
        #define IRC48M_TIMEOUT 1000
        if (++iIRC48M_USB_control >= IRC48M_TIMEOUT) {                   // if the switch-over is taking too long it means that the clock needs to be enabled in the USB controller
            POWER_UP_ATOMIC(4, USBOTG);                                  // power up the USB controller module
            USB_CLK_RECOVER_IRC_EN = (USB_CLK_RECOVER_IRC_EN_REG_EN | USB_CLK_RECOVER_IRC_EN_IRC_EN); // the IRC48M is only usable when enabled via the USB module
        }
        #endif
    }


Regards

Mark

418 Views
wilb
Contributor II

Hello Mark,

Thanks for your insight.  Does any issue arise if the clock source always establishes the USBOTG power-up and IRC48M configuration without waiting for the timeout?

Regards,

WilB. 

P.S. The link to uTasker MCG Configuration page remains most helpful especially the highlighted paths through the clock gates and muxes. If any takers emerge, a similar treatment of Low Power modes might also prove useful companions to the NXP Freescale application notes..

0 Kudos

418 Views
mjbcswitzerland
Specialist V

Wil

I think that the only draw-back of always enabling the USB module is the potentially unnecessary power consumption that comes with it.

For low power (Low leakage modes) there is a uTasker page at http://www.utasker.com/kinetis/LLWU.html
Since dynamic low power mode control is automated in the uTasker project it doesn't go into as much low-level detail but it may contain some things that help understand the modes (including some some videos and inks)

Regards

Mark

0 Kudos