AM6442: Sysconfig generating incompatible clock configurations for PRU_ICSS0/1

Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

SDK: Industrial communications v11.0.0.08

SysConfig 1.22.0+3893

In my current project both PRU_ICSS are used:

- PRU_ICSS0 is configured for RF50_0, as an Ethercat dependency.

- PRU_ICSS1 is configured for the RF51_0 core.

They run at different clock rates, but sysconfig is assigning the same parent clock for both (=2 in this case). This leads to one on them not working as intended: if I delay the startup of RF51_0, I can verify that ICSS0 runs OK, but "breaks" right after calling PowerClock_init().

/* Core R5F0_0 */
SOC_ModuleClockFrequency gSocModulesClockFrequency[] = {
    { TISCI_DEV_PRU_ICSSG0, TISCI_DEV_PRU_ICSSG0_CORE_CLK, 200000000,2},
    { TISCI_DEV_PRU_ICSSG0, TISCI_DEV_PRU_ICSSG0_UCLK_CLK, 192000000, SOC_MODULES_END},
    { TISCI_DEV_PRU_ICSSG0, TISCI_DEV_PRU_ICSSG0_IEP_CLK, 200000000,5},

    { SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END },
};

/* Core R5F1_0 */
SOC_ModuleClockFrequency gSocModulesClockFrequency[] = {

    { TISCI_DEV_PRU_ICSSG1, TISCI_DEV_PRU_ICSSG1_CORE_CLK, 333333333,2},
    { TISCI_DEV_PRU_ICSSG1, TISCI_DEV_PRU_ICSSG1_UCLK_CLK, 192000000, SOC_MODULES_END},
    { TISCI_DEV_PRU_ICSSG1, TISCI_DEV_PRU_ICSSG1_IEP_CLK, 200000000,5},

    { SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END },
};

  • Hi Martin,

    I have taken your inputs and working on it. Please allow some time to revert back.

    Regards,

    Tushar

  • This leads to one on them not working as intended: if I delay the startup of RF51_0, I can verify that ICSS0 runs OK, but "breaks" right after calling PowerClock_init().

    Can you please confirm, does it fails at Soc_ModuleSetClockFrequency() API?

    If yes, please share the moduleId and clockId used. 

    From my understanding, it seems that ICSSG0 is working fine on R5F0-0 core, but the ICSSG1 module is failing to work at R5F1-0.

  • Hi Tushar,

    Can you please confirm, does it fails at Soc_ModuleSetClockFrequency() API?

    If yes, please share the moduleId and clockId used. 

    The failure is right after calling SOC_moduleSetClockFrequencyWithParent() inside PowerClock_init(), from the R5F1_0.

    moduleId = 82

    clkId = 0

    From my understanding, it seems that ICSSG0 is working fine on R5F0-0 core, but the ICSSG1 module is failing to work at R5F1-0.

    Actually, ICSSG0 starts ok, but after this function call on the R5F1_0 it stops working correctly. ICSSG1 works as expected.

  • For me the above seems to be expected. As the parent clock for both the ICSSG0 & ICSSG1 are same. For the R5F0-0 when you try to set the parent clock for ICSSG0 to 200MHz, it works as expected. But when to try to set the same clock to 333MHz for ICSSG1 on R5F1-0, the ICSSG0 fails to work because the clock configuration for ICSSG0 also changes to 333MHz on the runtime which cause it to fail.

  • There are 3 separate clock sources that could be selected for the PRU clocks, as per
    [FAQ] PRU_ICSSG: How to check and set PRU Core Frequency in CCS?

    At first glance from what I wrote in that FAQ, 333MHz and 200MHz only come from 1 clock (hence why the same clock is being modified). Step 1 would be to check with the AM64x Clock Tree Tool and see if the other clock source can also be configured to provide either 200MHz, or 333MHz.

    Note that is exactly 5 ns per clock cycle (200MHz), and 3 ns (333.333333MHz).

    If 200MHz and 333MHz can only be provided by the same clock source, is there an option to run either firmware at 4 ns per clock cycle (250MHz, should use the bus clock instead of PRU_CORE clock), or at the clock frequency used by the other ICSSG subsystem?

    Regards,

    Nick

  • I double-checked the clock tree tool. The configuration of 200MHz to one ICSSG, and 333MHz to the other ICSSG, is supported in hardware.

    200MHz ICSSG should use MAIN_PLL2_HSDIV0_CLKOUT as a clock source.
    333MHz ICSSG should use MAIN_PLL0_HSDIV9_CLKOUT as the clock source.

    Regards,

    Nick