Clock cross-reference measurement fails in CLASSB package for STM32H7 MCU

[Arrhenius]

Hi,

I have integrated the CLASSB package to my application software. The HAL drivers are bypassed and custom drivers are used.

In the safety checks, all the tests are passed except the Clock cross-reference check.

Note: I am using default HSI clock for testing invariable and variable memory. In which case does my timer 16 initialization has to be changed ?

Kindly help me out resolving this issue.

Hoping to hear from the team soon.

Regards

Arrhenius

[Petr Sladecek]

Hello,

despite it is not clear if you target H7 single or dual core product nor if you face problem during startup or run time test, the clock measurement is handled via library source files stm32xx_STLclockstart.c and stm32xx_STLclockrun.c at principle. Crucial functions are STL_InitClock_Xcross_Measurement() handling the clock system initialization and TIM16_IRQHandler() interrupt handler both defined at stm32h7xx_it.c file at the library integration example. User has to set setup proper definitions and calls of macros HSI_LimitHigh() and HSI_LimitLow() (eventually HSE_LimitHigh() and HSE_LimitLow()) especially, too. Those are defined at stm32xx_STLparam.h and used for plausibility check of the clock system. User has to call them with correct parameter of the currently applied system clock frequency (see definition of SYSTCLK_AT_STARTUP or SYSTCLK_AT_RUN_HSE or SYSTCLK_AT_RUN_HSI at the header there). User must consider the checking period used to verify calculation of the clock cross reference ratio between system clock and LSI, too. Its length shall never drop below an interval corresponding to the number of LSI periods applied for the clock cross-measurement (set to eight by default).

I strongly suggest to find and read all occurrences of "cross" word at AN4435 user manual where you can find all these upper listed details.

Best regards,

Petr

[Arrhenius]

Hi Petr,

I have gone through the AN4435. I understood the implementation method followed by the CLASS B package.

I am not clear about the following,

a. How the below expressions are arrived.

/* HSE frequency above this limit considered as harmonics */

#define HSE_LimitHigh(fcy) ((uint32_t)(((fcy)/SFTY_LSI_Freq)*4u*5u)/4u) /* (HSEValue + 25%) */

/* HSE frequency below this limit considered as sub-harmonics*/

#define HSE_LimitLow(fcy) ((uint32_t)(((fcy)/SFTY_LSI_Freq)*4u*3u)/4u) /* (HSEValue - 25%) */

b. STL_initClock_Xcross_Measurement()

In STM32H7 CLASSB package 400MHz sys clock is used, hence timer16 is clocked by APB2 = 200MHz.

But, in my project I am using 64MHz sys clock during startup test and 256MHz during runtime. Will it impact the function STL_initClock_Xcross_Measurement?

I have done the cross reference test and the LSI period which I am getting with 64MHz sys clock and Timer clock 64MHz is 2033. But the HSE_LimitLow and HSE_Limit_High is 2343 and 3096 respectively. Since the LSI period isn't falling between the limits. The clock test is failing both during runtime and startup tests.

Kindly provide me some hints to solve the issue.

Hoping to hear from you ASAP.

P.S. FYI. The LSI period is captured during the test as an image it is attached to the thread.

Regards

Ajeeth Kumar

[Petr Sladecek]

There is no need to change setting of the cross-check measurement but just setup correct high and low acceptable limits at params header file. The calculations of the applied constants (the macros calculating these limits) are based on that. Interval of 8 consecutive periods of LSI clock is considered suppose sys clock/2 feeds the timer, so the measured value should be around ((sys_clock/2) / LSI clock) * 8. This means 8000 at startup and 32000 at run time at your case.

Then we apply 3/4 (75%) of those values for low limit at case of HSE (4/5 - 80% for HSI) and 5/4 (125%) for high limit at case of HSE (6/5 - 120% for HSI). This means you should accept results at interval 6400-9600 at startup and 25600-38400 at run time for HSI case.

Best regards,

Petr

[Arrhenius]

Hi Petr,

The limits according to you has to be between 6400 to 9600 during startup but i am getting the LSI period as 2033. Which doesn't fall under the the limits range right.

I have changed the sysclk macros. But still I am getting the LSI period as same value as 2033 only.

The update in the macro value is not impacting the LSI period. 

[Petr Sladecek · Accepted solution]

These macros neither influence LSI period nor any HW setting. Those are only definition of acceptable borders (constants) applied at comparison the LSI period measurement results. I don't know neither your clock tree nor timer input capture system configuration (you need to check configuration of both) and my calculation came from your information that you feed the timer by 32 MHz during the startup (64/2) and use default setting of the timer input capture system provided at the FW package. It is evident that it is not the case as the result of your measurement seems to be 8 times lower suppose timer is truly fed by 64MHz. It looks like you face either higher divider of the sys clock at timer input or do not apply 8 consecutive LSI periods but single one only for the input capture measurement. Please check and adapt either the borders definition or the hw configuration to match all off them together. The basic formula to obtain expected/ideal measurement value is quite straightforward:

measurement result = (timer input fcy / LSI fcy) * (number of LSI periods applied to capture the IC event)

Then the acceptable interval should be defined +/-20% from this expected/ideal value if HSI feeds the timer. There is no mystery behind.

Best regards,

Petr