This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6442: PRUs running at different clock speed

Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Dear TI,

in a proprietary design; we are using ICSSG0 on core R5F0_0 for EtherCat node (Beckhoff slave implementation). We took over the sample design, with modifications for use of ICSSG0 instead of ICSSG1. The EtherCat slave is stable in our design. We use the default clock values (200MHz) from the sample :

SOC_ModuleClockFrequency gSocModulesClockFrequency[] = {
    { TISCI_DEV_PRU_ICSSG0, TISCI_DEV_PRU_ICSSG0_CORE_CLK, 200000000 },
    { TISCI_DEV_PRU_ICSSG0, TISCI_DEV_PRU_ICSSG0_UCLK_CLK, 192000000 },
    { TISCI_DEV_PRU_ICSSG0, TISCI_DEV_PRU_ICSSG0_IEP_CLK, 200000000 },
    { SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END },
};

On core R5F1_0 we have a realtime application which is using ICSSG1. It is time critical and 200MHz is not sufficient, so we use 300MHz clock.

SOC_ModuleClockFrequency gSocModulesClockFrequency[] = {
    { TISCI_DEV_PRU_ICSSG1, TISCI_DEV_PRU_ICSSG1_CORE_CLK, 300000000 },
    { TISCI_DEV_PRU_ICSSG1, TISCI_DEV_PRU_ICSSG1_UCLK_CLK, 192000000 },
    { TISCI_DEV_PRU_ICSSG1, TISCI_DEV_PRU_ICSSG1_IEP_CLK, 300000000 },
    { TISCI_DEV_UART3, TISCI_DEV_UART3_FCLK_CLK, 48000000 },
    { SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END },
};
Whenever ICSSG1 is set to 300MHz, then the EtherCat function breaks. The program starts normal, but Twincat doesn't see the Ethercat slave.
When I change ICSSG1 to 200MHz, then EtherCat works fine.

Is there any dependency between the clocks of both PRUs? Why does the Ethercat function break?

kind regards,
Marc Schouteeten



  • Hi Marc,

    Thanks for your query.

    I will check on this and get back to you.

    Best Regards

    Ashwani

  • In the meanwhile, I did some code inspection and debugging;

    I also went through the init of the clocks in the cores :

    System_init()

      --> PowerClock_init()

        --> Module_clockSetFrequency()

          --> SOC_moduleSetClockFrequency()

            --> Sciclient_pmSetModuleClkParent()

            --> Sciclient_pmQueryModuleClkFreq()

            --> Sciclient_pmSetModuleClkFreq()

     

    Is it possible that the SYSCONFIG tool sets both PRU CORE frequencies from the same 'parent' clock source? Since the init code for both PRUs is executed on seperate R5 cores; they could basically overwrite the other core's initialisation? Thus creating a race condition where the core which initialises last, will get the desired clock frequency?

    I was trying to initialise one of the cores from the second parent clock; and there query for a suitable clock frequency. The tisci_msg_query_freq_req()  with a +/- 40 MHz range returned a clock of 333.333333 MHz. This workaround needs to be validated still..

    kind regards,

    Marc

  • Hi Marc,

    My assumption are:

    1. You are selecting ICSSG0 and ICSSG1 and setting clock using example.syscfg
    2. Then compilation your example with result in below code addition. which will enable/configure respective module clk.

    correct?

    Best Regards

    Ashwani

  • Hi, the PRUs are setup on different R5 cores; so the code above is in 2 different places; running on different cores.

  • Marc,

      I faced similar issues when setting PRU clock from SYSCONFIG tool. I am doing the PRU clock config in PRU code - see snippet below. This can also be moved to ARM side before PRU on ICSS_G1 is going out of reset.

    Long term, SYSCONFIG should be fixed on this issue.

    - Thomas

    ;************************************* setup clock ******************************************
    ; run core clock 300 MHz (PLL2)
    ; run iep clock 500 MHz  (PLL0)


    setup_clocks:
    ; core clock - 333 MHz slected to get 3 ns IO resolution
    ; core clock options:
    ; ICSSG0_CLKMUX_SEL: bit 0 = 1 PLL0, bit 0 = 0 PLL2
    ; MAIN_PLL0_HSDIV9: 2 (333 MHz), 3 (250 MHz)
    ; MAIN_PLL2_HSDIV2: 5 (300 MHz), 7 (225 MHz)
    ; ICSSG_CFG: iep_clk to follow core clock
    ;
    ; iep clock options
    ; ICSSG0_CLKMUX_SEL: bit 16-17:
    ; 0h - MAIN_PLL2_HSDIV5_CLKOUT
    ; 1h - MAIN_PLL0_HSDIV6_CLKOUT
    ; 7h - SYSCLK0 (500 MHz) - not recommended!!!
    ; recommend to run both clocks from same PLL0
    ; e.g. PLL0 iep_clk = 500 MHz, core_clock = 333 MHz

    ; configure ICSS clocks
    ; unlock CTRLMMR config register
    ; partition 2
        ldi32    r2, 0x43009008  ; LOCK0 KICK0 register
        ldi32    r3, 0x4300900c  ; LOCK0 KICK1 register
        ldi32    r4, 0x68EF3490  ; kick 0
        ldi32    r5, 0xD172BC5A  ; kick 1
        sbbo     &r4, r2, 0, 4
        sbbo     &r5, r3, 0, 4

    ; ICSSG0_CLKMUX_SEL:    
    ; 0h - MAIN_PLL2_HSDIV2_CLKOUT,
        ldi32    r2, 0x43008040
        ldi32     r3, 0x00010000
        sbbo     &r3, r2, 0, 4

     .if(1)
    ; run iep_clk with core clock    
        ldi32    r2, 0x00026030
        ldi32     r3, 0x00000001
        sbbo     &r3, r2, 0, 4
     .endif

    ; unlock PLL0 ctrl register
        ldi32    r2, 0x00680010  ; LOCK0 KICK0 register
        ldi32    r3, 0x00680014  ; LOCK0 KICK1 register
        sbbo     &r4, r2, 0, 4
        sbbo     &r5, r3, 0, 4

    ; set MAIN_PLL0_HSDIV9 to 2 for core_clock =333MHz (3 for 250 MHz)
        ldi      r2.b0, 2
        ldi32    r3, 0x006800a4
        sbbo     &r2, r3, 0, 1

    ; set MAIN_PLL0_HSDIV6_CLKOUT iep_clock from PLL0 (1 = 500 MHz, 2 = 333 MHz, 3 = 250 MHz)
        ldi      r2.b0, 2
        ldi32    r3, 0x00680098
        sbbo     &r2, r3, 0, 1
        
    ; unlock PLL2 ctrl register
        ldi32    r2, 0x00682010  ; LOCK0 KICK0 register
        ldi32    r3, 0x00682014  ; LOCK0 KICK1 register
        sbbo     &r4, r2, 0, 4
        sbbo     &r5, r3, 0, 4

    ; set core clock MAIN_PLL2_HSDIV0 to 5 for 300 MHz (7 for 225 MHz, 5 for 333 MHz)
        ldi      r2.b0, 5
        ldi32    r3, 0x00682080
        sbbo     &r2, r3, 0, 1

    ; set MAIN_PLL2_HSDIV5_CLKOUT iep_clock from PLL2
        ldi      r2.b0, 5
        ldi32    r3, 0x00682094
        sbbo     &r2, r3, 0, 1

        jmp         return_clocks

  • Thank you Thomas,

    I have taken the easier approach of copying basically the SYSCONFIG generated routines; renaming it to *_custom()  and then modifying and forcing the second R5F core to setup the second ICSSG1 on the second parent clock.

    So I'm doing the init from the ARM side.

    Functionality is confirmed by now!

    thank you for your message!

    kind regards,
    Marc