Frequency Calculation bug when using ExtClk but ok with IMO.

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
azBlock1
Level 1
Level 1
First solution authored 10 sign-ins 5 sign-ins

I am using v3.0 tools and visual studio code. This is more of a bug report but also a reference for anyone hitting this problem themselves.

I have a custom board with CY8C6244AZI-S4D93 with an external 12Mhz (12000000hz) oscillator going into P0[0]. This is the source signal for PLL which is 150Mhz.

azBlock1_0-1672185227236.png

 

I am running a dual core software app with CM0 and CM4 cores. CM0 does the initialization of peripherals and CM4 runs the main application.

Both CM0 and CM4 have an infinite while loop.

Problem is that when CM0 initializes the external clock frequency with Cy_SysClk_ExtSetFrequency(CY_CFG_SYSCLK_EXTCLK_FREQ) this doesnt propagate to the CM4 core.

This causes timing error with the various delay functions.

 

This is verified by calling Cy_SysClk_ExtClkGetFrequency() in both CM0 and CM4 main loops.

In the CM0 it correctly returns 12000000, in CM4 it returns 0. This causes other things to break down such as Cy_SysClk_PllGetFrequency(1) from CM4.

 

My workaround is to call Cy_SysClk_ExtClkSetFrequency(12000000) as first line of the CM4 app.

This seems like an odd workaround though, since it works correctly when using the IMO.

Either im doing something wrong or the software doesnt account for an ExtClk properly when initializing using the default initializers.

 

0 Likes
1 Solution

Hello,

I dont think im able to attach the project here but i believe i understand the underlying behavior enough to explain it in more depth.

For Question 1.

EXTCLK is configured as 12MHz with 30ppm tolerance. PATH_MUX1 is configured to use EXTCLK. PLL is configured to generate 150Mhz with Min Jitter optimization. CLK_HF0 is set to CLK_PATH1. This produces the following clocking config:

azBlock1_0-1672252809965.png

This causes CM0 to initialize the PLL. I can verify that the PLL is indeed working by using CLK_HF1 output to P0[5] to output CLK_PATH1 with a /4 divider. This gives me 37.5Mhz at the output once CM0 goes through the initialization. Trouble is the software in the CM4 doesnt configure its internal frequency 150Mhz, rather it keeps it at 8Mhz. This causes complications when doing any functions that rely on that frequency for calculation, example Cy_SysLib_DelayUs(100) doesnt work correctly when called from CM4 core.

For Question 2:

The problem observed is that when using Cy_SysLib_DelayUs(100) in the CM4 core loop the delay was not correct. This was measured by using one of the 32 bit counters configured with 5Mhz count frequency and recording start and stop time.

 

For question 3 and 4:

I am letting the cybsp_init() handle everything as far as setup. And it seems to correctly initialize the PLL and make it run. It just seems to not update the variables the software uses for timing calculations.

Specifically the problem is as follows.

In CM4 project when i dont call at the top

 

    Cy_SysClk_ExtClkSetFrequency(EXTCLK_OSCILATOR_FREQ);
    SystemCoreClockUpdate();

 

and i use

 

Cy_SysLib_DelayUs(100);

 

The calculation is incorrect where the internal cy_delayFreqMhz is set to 8.

 

But if i apply my fix then the cy_delayFreqMhz is correct at 150. Keep in mind in both cases i can see that the PLL is at 150Mhz because CLK_HF1 is outputting PLL/4 and i see 37.5Mhz at the output pin.

 

Ive narrowed it down to the following.

With just default initialization code, no fix, in the CM0 core i set up the loop as follows:

    for (;;)
    {
        volatile uint32_t extClk_CM0 = Cy_SysClk_ExtClkGetFrequency();

        volatile bool t = false;
    }

and in CM4 i set up the loop as follows:

    while(true)
    {
        volatile uint32_t extClk_CM4 = Cy_SysClk_ExtClkGetFrequency();

        volatile int t1 = 0;
    }

 

After i debug into the project and put a breakpoint in CM0 core loop extClk_CM0 = 12000000. But if i put a breakpoint in the CM4 loop then extClk_CM4 = 0. This i believe is causing the various issues for calculations.

View solution in original post

0 Likes
3 Replies
LinglingG_46
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 10 questions asked

1: Could you attach your test project here? As my understanding, if set up the Ext clock and choose the pin 0_0. It should be configured in the startup code. The clock setup API is "void SystemInit(void)". Depending on the clock routing tree, I think if the CM0+ can get the right clock frequency, it means the CM4 clock it right also.

LinglingG_46_0-1672218249676.png

We should choose the path mux source clock "EXTCLK".

LinglingG_46_1-1672219142693.png

 

2; How to understand "Problem is that when CM0 initializes the external clock frequency with  Cy_SysClk_ExtSetFrequency(CY_CFG_SYSCLK_EXTCLK_FREQ) this doesnt propagate to the CM4 core."? Why do you need to use this API to config?

3: First of all, we should confirm that we give the right clock to P0_0, then we should confirm that we have given it to path Mux like the screenshot we give.

4: If we only use "Cy_SysClk_ExtSetFrequency(CY_CFG_SYSCLK_EXTCLK_FREQ)" to set the ext clock, and don't give it to path_mux , if so, I think we should check we have a right configure.

 

 

0 Likes

Hello,

I dont think im able to attach the project here but i believe i understand the underlying behavior enough to explain it in more depth.

For Question 1.

EXTCLK is configured as 12MHz with 30ppm tolerance. PATH_MUX1 is configured to use EXTCLK. PLL is configured to generate 150Mhz with Min Jitter optimization. CLK_HF0 is set to CLK_PATH1. This produces the following clocking config:

azBlock1_0-1672252809965.png

This causes CM0 to initialize the PLL. I can verify that the PLL is indeed working by using CLK_HF1 output to P0[5] to output CLK_PATH1 with a /4 divider. This gives me 37.5Mhz at the output once CM0 goes through the initialization. Trouble is the software in the CM4 doesnt configure its internal frequency 150Mhz, rather it keeps it at 8Mhz. This causes complications when doing any functions that rely on that frequency for calculation, example Cy_SysLib_DelayUs(100) doesnt work correctly when called from CM4 core.

For Question 2:

The problem observed is that when using Cy_SysLib_DelayUs(100) in the CM4 core loop the delay was not correct. This was measured by using one of the 32 bit counters configured with 5Mhz count frequency and recording start and stop time.

 

For question 3 and 4:

I am letting the cybsp_init() handle everything as far as setup. And it seems to correctly initialize the PLL and make it run. It just seems to not update the variables the software uses for timing calculations.

Specifically the problem is as follows.

In CM4 project when i dont call at the top

 

    Cy_SysClk_ExtClkSetFrequency(EXTCLK_OSCILATOR_FREQ);
    SystemCoreClockUpdate();

 

and i use

 

Cy_SysLib_DelayUs(100);

 

The calculation is incorrect where the internal cy_delayFreqMhz is set to 8.

 

But if i apply my fix then the cy_delayFreqMhz is correct at 150. Keep in mind in both cases i can see that the PLL is at 150Mhz because CLK_HF1 is outputting PLL/4 and i see 37.5Mhz at the output pin.

 

Ive narrowed it down to the following.

With just default initialization code, no fix, in the CM0 core i set up the loop as follows:

    for (;;)
    {
        volatile uint32_t extClk_CM0 = Cy_SysClk_ExtClkGetFrequency();

        volatile bool t = false;
    }

and in CM4 i set up the loop as follows:

    while(true)
    {
        volatile uint32_t extClk_CM4 = Cy_SysClk_ExtClkGetFrequency();

        volatile int t1 = 0;
    }

 

After i debug into the project and put a breakpoint in CM0 core loop extClk_CM0 = 12000000. But if i put a breakpoint in the CM4 loop then extClk_CM4 = 0. This i believe is causing the various issues for calculations.

0 Likes

1: Please download the latest Modus Toolbox tool from the linker (version 3.0.0.9369): 

https://softwaretools.infineon.com/tools/com.ifx.tb.tool.modustoolbox?_ga=2.123477644.643108219.1675...

mtb-pdl-cat1 version: release-v3.2.0

2: The CM4 gets the right clock in the latest version.

 

0 Likes