Change CPU frequency ?

[dcasier]

I notice that the machine_freq (set) function is not implemented for the m.iMX RT port.

I'm not sure I'm capable of proposing an implementation. There are a lot of elements to control/check for a hot change?

I tried a hard implementation by changing the BOARD_BOOTCLOCKRUN_CORE_CLOCK parameter and recompiling. This doesn't seem to be enough (cpu still at 600 Mhz).

Am I way off the mark?

[robert-hh]

Changing BOARD_BOOTCLOCKRUN_CORE_CLOCK does indeed not have any effect. The clock configuration is done in the respective boards/MIMXRTxxx_clock_config.c files and before that in the ROM code. Detailed information about the clock system can be found in the respective chapters of the Reference Manual. It looks complicated, and there a quite a few peripherals which require a fixed frequency. So just changing the ARM clock may not drop the power consumption substantially, if that is your interest.

[dcasier]

Indeed, the aim is to reduce power consumption to preserve the board in hot, confined environments.

I'll try to get some inspiration from teensyduino's code: https://github.com/PaulStoffregen/cores/blob/master/teensy4/clockspeed.c

Thanks for the answer

[dcasier]

By applying these modifications, I have good results (warning: do not apply my tests without checking) :

--- MIMXRT1062_clock_config_ori.c       2023-08-19 11:16:07.364496563 +0200
+++ MIMXRT1062_clock_config.c   2023-08-19 11:51:20.146583315 +0200
const clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
-    .loopDivider = 100, /* PLL loop divider, Fout = Fin * 50 */
+    .loopDivider = 63, /* PLL loop divider, Fout = Fin * 50 */
     .src = 0,           /* Bypass clock source, 0 - OSC 24M, 1 - CLK1_P and CLK1_N */
 };
-    /* Setting the VDD_SOC to 1.275V. It is necessary to config AHB to 600Mhz. */
-    DCDC->REG3 = (DCDC->REG3 & (~DCDC_REG3_TRG_MASK)) | DCDC_REG3_TRG(0x13);
+    /* Setting the VDD_SOC to 1.15V (< 528Mhz) */
+    DCDC->REG3 = (DCDC->REG3 & (~DCDC_REG3_TRG_MASK)) | DCDC_REG3_TRG(0xe);
     /* Set IPG_PODF. */
-    CLOCK_SetDiv(kCLOCK_IpgDiv, 3);
+    CLOCK_SetDiv(kCLOCK_IpgDiv, 1);
     /* Set ARM_PODF. */
-    CLOCK_SetDiv(kCLOCK_ArmDiv, 1);
+    CLOCK_SetDiv(kCLOCK_ArmDiv, 4);

--- MIMXRT1062_clock_config_ori.h       2023-08-17 11:50:27.191624087 +0200
+++ MIMXRT1062_clock_config.h   2023-08-20 19:15:33.008385375 +0200
-#define BOARD_BOOTCLOCKRUN_CORE_CLOCK 600000000U /*!< Core clock frequency: 600000000Hz */
+#define BOARD_BOOTCLOCKRUN_CORE_CLOCK 151200000U /*!< Core clock frequency: 151200000Hz */

-#define BOARD_BOOTCLOCKRUN_AHB_CLK_ROOT 600000000UL
+#define BOARD_BOOTCLOCKRUN_AHB_CLK_ROOT 151200000UL

-#define BOARD_BOOTCLOCKRUN_IPG_CLK_ROOT 150000000UL
+#define BOARD_BOOTCLOCKRUN_IPG_CLK_ROOT 75600000UL

however, the processing of delays in my programs is not good (e.g. a time.sleep(5) will take 5 sec).

I had understood the reference to be SystemCoreClock(=BOARD_BOOTCLOCKRUN_CORE_CLOCK) but that doesn't seem to be the case.

I'm wrong in thinking that it's necessarily an oversight on my part in one of the 2 files MIMXRT1062_clock_config.[hc]?

[robert-hh]

the processing of delays in my programs is not good (e.g. a time.sleep(5) will take 5 sec).

sleep(5) takes now 5s?

Coincidentally I tried to change ARM_PLL this afternoon as well, setting it to 300Mhz. That worked. Code execution got ~20% slower, and the current consumption of a Teensy4.1 dropped from 78mA to 56mA. Only reflashing the code after setting the change back was tricky. So that should better go into machine.freq() and the CPU should start at 600Mhz as usual.

[robert-hh]

I see that the delays are affected by the ARM clock setting as well. I did not expect that since they are driven by GPT2, which is configured for the 24Mhz crystal as source,

[robert-hh]

Using fixed setting for just 150, 300 and 600 MHz the clocks can be balanced such that the IPG clock is still at 150Mhz. Code snippet below, using your changes as template. But the power consumption drops not dramatically. Just from 72mA to 54 mA at a Teensy 4.1.

#include CLOCK_CONFIG_H

STATIC mp_obj_t machine_freq(size_t n_args, const mp_obj_t *args) {
    if (n_args == 0) {
        return MP_OBJ_NEW_SMALL_INT(mp_hal_get_cpu_freq());
    } else {
        clock_arm_pll_config_t armPllConfig_BOARD_BootClockRUN = {
            .loopDivider = 100, /* PLL loop divider, Fout = Fin * loopDivider / 2 */
            .src = 0,           /* Bypass clock source, 0 - OSC 24M, 1 - CLK1_P and CLK1_N */
        };
        uint32_t freq = mp_obj_get_int(args[0]);
        if (freq == 150000000) {
            armPllConfig_BOARD_BootClockRUN.loopDivider = 75;
            CLOCK_InitArmPll(&armPllConfig_BOARD_BootClockRUN);   // 900 MHz Pll
            CLOCK_SetDiv(kCLOCK_ArmDiv, 5);  // Div by 6
            CLOCK_SetDiv(kCLOCK_IpgDiv, 0);  // Div by 1
            /* Setting the VDD_SOC to 1.15V (< 528Mhz) */
            DCDC->REG3 = (DCDC->REG3 & (~DCDC_REG3_TRG_MASK)) | DCDC_REG3_TRG(0xe);
        } else if (freq == 300000000) {
            armPllConfig_BOARD_BootClockRUN.loopDivider = 75;
            CLOCK_InitArmPll(&armPllConfig_BOARD_BootClockRUN);  // 900 MHz Pll
            CLOCK_SetDiv(kCLOCK_ArmDiv, 2);  // Div by 3
            CLOCK_SetDiv(kCLOCK_IpgDiv, 1);  // Div by 2
            /* Setting the VDD_SOC to 1.15V (< 528Mhz) */
            DCDC->REG3 = (DCDC->REG3 & (~DCDC_REG3_TRG_MASK)) | DCDC_REG3_TRG(0xe);
        } else if (freq == 600000000) {
            /* Setting the VDD_SOC to 1.275V. It is necessary to config AHB to 600Mhz. */
            DCDC->REG3 = (DCDC->REG3 & (~DCDC_REG3_TRG_MASK)) | DCDC_REG3_TRG(0x13);
            armPllConfig_BOARD_BootClockRUN.loopDivider = 100;
            CLOCK_InitArmPll(&armPllConfig_BOARD_BootClockRUN);   // 1200 MHz Pll
            CLOCK_SetDiv(kCLOCK_IpgDiv, 3);  // Div by 4
            CLOCK_SetDiv(kCLOCK_ArmDiv, 1);  // Div by 2
        }
        return mp_const_none;
    }
}
STATIC MP_DEFINE_CONST_FUN_OBJ_VAR_BETWEEN(machine_freq_obj, 0, 1, machine_freq);

[robert-hh]

I finished a branch which includes the freq setting for all MCUs except MIMXRT1176. It is here: https://github.com/robert-hh/micropython/tree/mimxrt_freq. The power saving is usually pretty low. Teensy with ~30% is the largest. So I do not know whether I should make a PR for it. Maybe only for API consistency.

[robert-hh]

I found that the card could reset when going from 150 (or 300) to 600Mhz.

I ran into that as well and swapped two lines. The code in the linked branch should work, and I changed the above code example too.

[robert-hh]

Yesterday I found the reason why your initial change affected the time functions. The perclk_root frequancy must not be lower than 48 MHz (24MHz crystal freq * 2). If I change PERCLK_PODF from 2 to 1, IPG_CLK_ROOT can be lowered down to 48MHz, and the ARM_CLK could be lowered down to 88MHz minimum. But the effect on power consumption is small, so I did not implement it. At least now I set at the 150MHz freq setting the IPG_CLK and PER_CLK values to 50MHz. That saves a few mA.

[dcasier]

Thanks for the info

Following your message, I did a search and came across this document: https://www.nxp.com/docs/en/application-note/AN12245.pdf

These elements are detailed in point "13.4 Power management" of the reference manual.

If I find the time and manage to understand/target the registers to be modified, I'll test by implementing a "low power run (24 Mhz)" profile in the "machine.freq" function.

[dcasier]

How to use i.MX RT Lower Power Feature => https://www.nxp.com/docs/en/application-note/AN12085.pdf

[robert-hh]

Thank you for the notes & links. I'm well aware of section 13.4 . The 24MHz mode would not work for a operational device, since most of the peripherals would have to be switched off. It could be used for something like lightsleep, which is currently not implemented..

[firehurtnova11]

Yup, I was also having this same issue. But after getting here, I did fix it with the help of you guys.

[dcasier]

Hi robert-hh,
The branch no longer exists ?

[robert-hh]

I moved it to an archived copy of my repository. But I can put it back, if you need it.

[dcasier]

Maybe place a diff here for archiving? For my part, I haven't touched it since our last exchanges and I wanted to compare with what I had done.
Thks.

[robert-hh]

It's back and up-to-date.