Dear Forum,
We've noticed that in all multi-core examples (IMXRT1170 SDK) clock_config.c initialises many of the same clocks twice: on CM7 and second time on CM4 core. Sometimes the same can be said about pin_mux.c According to the docs, CM7 core runs first, why should CM4 do the same job again?
Example from multicore/evkmimxrt1170_hello_world_cm4 clock_config.c:
/* Configure ADC1 using OSC_RC_48M_DIV2 */
rootCfg.mux = kCLOCK_ADC1_ClockRoot_MuxOscRc48MDiv2;
rootCfg.div = 1;
CLOCK_SetRootClock(kCLOCK_Root_Adc1, &rootCfg);
Then from multicore/evkmimxrt1170_hello_world_cm7 clock_config.c:
/* Configure ADC1 using OSC_RC_48M_DIV2 */
rootCfg.mux = kCLOCK_ADC1_ClockRoot_MuxOscRc48MDiv2;
rootCfg.div = 1;
CLOCK_SetRootClock(kCLOCK_Root_Adc1, &rootCfg);
We saw preprocessor ifdefs for some cases:
But even weirder, on some examples CM4 touches even CM7 clocks. From multicore/evkmimxrt1170_hello_world_cm4 clock_config.c:
/* Module clock root configurations. */
/* Configure M7 using ARM_PLL_CLK */
rootCfg.mux = kCLOCK_M7_ClockRoot_MuxArmPllOut;
rootCfg.div = 1;
CLOCK_SetRootClock(kCLOCK_Root_M7, &rootCfg);
1. Is it safe to remove same clock initialisation from CM4 or is there something else going on?
2. Why all examples keeps this convention to initialise same clocks twice?
3. Is it possible to get undefined behaviour when CM4 (which runs later) changes CM7 clocks?
4. What is the best approach when using auto-generated clock_config.c and pin_mux.c from MCUXpresso Config Tools for multicore systems?
Regards,
Solved! Go to Solution.
Hi @Juozas ,
Any clocks don't need initializing twice. The clock configuring code is there but the second core never calls it. You can check the main() function of second core.
Regards,
Howard
Hi @Juozas ,
Any clocks don't need initializing twice. The clock configuring code is there but the second core never calls it. You can check the main() function of second core.
Regards,
Howard
Any comments on this?