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.

TMS570LS3137: CDDIS Register settings

Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

Hi Team,

In map clocks configuration, why vclk4 is set ON (from halcogen), even though controller doesn't support vclk4?

    *sys1_cddis = (Uint32)(((Uint32)0U << 4U ) /* AVCLK1 ON */
                  | (Uint32)((Uint32)0U << 5U ) /* AVCLK2 ON */
                  | (Uint32)((Uint32)0U << 8U ) /* VCLK3 ON */
                  | (Uint32)((Uint32)0U << 9U ) /* VCLK4 ON */
                  | (Uint32)((Uint32)1U << 10U) /* AVCLK3 OFF */
                  | (Uint32)((Uint32)0U << 11U)); /* AVCLK4 ON */

Also, in map clocks, Why do we need to set bit 8 (Which is a reserved as per spnu499c.pdf) to 1?

    *sys2_clk2cntl = (*sys2_clk2cntl & 0xFFFFF0F0U)
                     | (Uint32)((Uint32)1U << 8U)
                     | (Uint32)((Uint32)8U << 0U);

Thank you,

Baba.

  • Hello,

    You are right, VCLK4 is not supported on LS3137. Writing 0 and 1 to bit 9 has no effect to clock settings.

    I will report this to HALCoGen team. Thanks

  • Thanks QJ Wang.

    Also, in map clocks, Why do we need to set bit 8 (Which is a reserved as per spnu499c.pdf) to 1 as mentioned below?

        *sys2_clk2cntl = (*sys2_clk2cntl & 0xFFFFF0F0U)
                         | (Uint32)((Uint32)1U << 8U)
                         | (Uint32)((Uint32)8U << 0U);

    As per note mentioned in section 2.5.1.44, HALCoGen code in mapclocks is not matching, Please provide more details over it.

        systemREG1->CLKCNTL  = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
                             | (uint32)((uint32)8U << 24U);
        systemREG1->CLKCNTL  = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
                             | (uint32)((uint32)8U << 16U););

    Thank you,

    Baba.

  • Hello,

    1. Bit[11:8] of CLK2CNTRL is used as VCLK4 divider. This field should not used for LS3137 device. We will correct it or add a note in the release notes. Thanks

    2. VCLK2 must always be greater than or equal to VCLK. In addition, the VCLK and VCLK2 clock ratios must not be changed simultaneously. The application must configure the VCLK2 ratio, read back the contents of the CLKCNTL register, and then configure the VCLK ratio.

    systemREG1->CLKCNTL  = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
                             | (uint32)((uint32)8U << 24U);
    systemREG1->CLKCNTL  = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
                             | (uint32)((uint32)8U << 16U););

    The code follow the VCLK and VCLK2 clock ratio restrictions:

    1. VCLK2 = VCLK

    2. Write VCLK2 ratio first

    3. Read CLKCNTL ((systemREG1->CLKCNTL), then write VCLK ratio

  • Hi,

    The halcogen generated code as mentioned below is giving a cpu fault.

    systemREG1->CLKCNTL  = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
                             | (uint32)((uint32)8U << 24U);
    systemREG1->CLKCNTL  = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
                             | (uint32)((uint32)8U << 16U));

    Its working fine, by changing the code as mentioned below (meets the clock restrictions in the Note) for increasing the clock divider.

    systemREG1->CLKCNTL  = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
                             | (uint32)((uint32)8U << 16U));

    systemREG1->CLKCNTL  = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
                             | (uint32)((uint32)8U << 24U);

    Please confirm generated code from halcogen is correct?

    Thank you,

    Baba.

  • Hello,

    The modified code doesn't meet the VCLK and VCLK2 clock setting restriction. The same clock ratio for VCLK and VCLK2 is fine. But the VCLK2 should configured first, then VCLK. The modified code swaps the sequence.

    I am doing the test with your modified code.

  • Hello,

    In your code, the GCLK:VCLK ratio is 9. As VIM#27 states, the VIM may return the phantom interrupt vector instead of the real interrupt vector if the ratio is greater than 3:1 for HW vectored more, or 5:1 for SW vectored mode.

    The workaround is to change the ratio to 1:1 or 2:1.

  • Hi,

    Note is regarding VCLK and VCLK2 clock ratio restrictions. My code does the VCLKR setting first than setting VCLK2R as we are increasing the divider(1 to 9) which is matching with the instructions in the Note.

    Please explain the reason for your work around GCLK:VCLK ratios.

    Thank you,

    Baba.

  • Hello,

    You said you get CPU fault If VCLK/BVCK2 in CLKCNTL is configured using HALCoGen generated code. I did tests, and did get any error. My PLL setting is 180MHz.

    I checked the ECLK which is configured to output VCLK/2, and I got correct clock output. Can you please provide more details to me to reproduce the issue?

  • Hello,

    If the ratio of GCLK and VCLK is greater than 3, the interrupt request may be vectored to the phantom interrupt route instead of the correct service routine. It is not related to the issue you mentioned. Just let you be aware because the GCLK/VCLK in your configuration is > 3.

  • Hello,

    Can you please provide more details for me to reproduce the issue? or you can post your test case, so I will do test with your project. Thanks

  • Hello,

    I could not reproduce the problem with the settings recommended in TRM. Can you please provide your test case for me to reproduce the issue. Thanks

  • Hi Wang,

    As per TRM, VCLK2R and VCLKR fields are initialized to 1 on power on reset. Now, if we want to configure it 0 (where the divider is decreasing ), we have to update VLCK2R first followed by VCLKR. On the other hand, if we want to increase the divider, then we have to configure VCLKR first followed by VCLK2R.

    Looks like this is not happening in the halcogen generated code. Can you please check and confirm on this?

    Regards,
    M.Sreenivasan.

  • Hello,

    I did tests yesterday and today. The notes in TRM about the VCLK and VCLK2 clock ratio restrictions is correct. In my test, the ECLK output is correct for every VCLK setting.

    /*HCLK=90MHz. Monitor ECLK = VCLK1/9; VCLK2R =0, VCLKR=0; VCLK1=HCLK/(VCLKR+1) */
    /* VCLK1 = 180/1 = 180MHz; ECLK=180/9=20MHz */
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
    | (uint32)((uint32)0U << 24U); /*VCLK2R*/
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
    | (uint32)((uint32)0U << 16U); /*VCLKR*/

    /* VCLK1 = 180/3 = 60MHz; ECLK=60/9=6.67MHz */
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
    | (uint32)((uint32)2U << 24U); /*VCLK2R*/
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
    | (uint32)((uint32)2U << 16U); /*VCLKR*/

    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
    | (uint32)((uint32)4U << 24U); /*VCLK2R*/
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
    | (uint32)((uint32)4U << 16U); /*VCLKR*/

    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
    | (uint32)((uint32)6U << 24U); /*VCLK2R*/
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
    | (uint32)((uint32)6U << 16U); /*VCLKR*/

    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
    | (uint32)((uint32)4U << 24U); /*VCLK2R*/
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
    | (uint32)((uint32)4U << 16U); /*VCLKR*/

    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
    | (uint32)((uint32)2U << 24U); /*VCLK2R*/
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
    | (uint32)((uint32)2U << 16U); /*VCLKR*/

    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
    | (uint32)((uint32)1U << 24U); /*VCLK2R*/
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
    | (uint32)((uint32)1U << 16U); /*VCLKR*/

    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xF0FFFFFFU)
    | (uint32)((uint32)0U << 24U); /*VCLK2R*/
    systemREG1->CLKCNTL = (systemREG1->CLKCNTL & 0xFFF0FFFFU)
    | (uint32)((uint32)0U << 16U); /*VCLKR*/