Hi,
I have been getting to grips with Chibios and have recently moved from an STM32nucleo board to a custom board with still with an STM32f7 but at a much higher clock frequency. I thought I had reconfigured the frequencies correctly but found the delaying function osalSysPolledDelayX(TIME_US2I(500)) to be running much faster than the expected 500us by toggling an LED and a scope.
I found CH_CFG_ST_FREQUENCY in chconf.h and played around with it and found it changed the delay routine but was unable to set it to 216000000 (216MHz sys clock frequency) as its out of range of the timer prescaler.
My question is, how to I set the system tick frequency to the correct value or do I need to daisy chain timers to act as another prescaler? Or am I looking in completely the wrong place altogether?
I am using timer 5 as the system timer
STM32f777 with 25MHz crystal and sysclk 216MHz
Thanks for any help
Simon
setting CH_CFG_ST_FREQUENCY
- RoccoMarco
- Posts: 655
- Joined: Wed Apr 24, 2013 4:11 pm
- Location: Munich (Germany)
- Has thanked: 83 times
- Been thanked: 67 times
- Contact:
Re: setting CH_CFG_ST_FREQUENCY
Ciao,
the CH_CFG_ST_FREQUENCY is the frequency of the kernel tick and fix the maximum resolution of counting. This impact all these activities related to timing such the sleep fixing the minimum amount of time that scheduler is able to count. E.g. if you choose 10000 as CH_CFG_ST_FREQUENCY (i.e. 10KHz) the lower limit to sleep time will be 100us (1/10KHz) with incertitude of 1 tick.
This is anyway unrelated to your problem. I think that there is a misconfiguration in the mcuconf.h with PLL sources/divider/multiplier. I suggest you to copy mcuconf from a default demo related to that MCU (i.e mcu conf of RT-STM32F767ZI-NUCLEO144 witch has the same clock tree)
If the PLL source is HSE take care to readapt also board files where the HSE frequency is defined. It should be now 25000000 (i.e. 25 MHz). This most likely would require to choose new divider/multiplier in comparison to default demo.
the CH_CFG_ST_FREQUENCY is the frequency of the kernel tick and fix the maximum resolution of counting. This impact all these activities related to timing such the sleep fixing the minimum amount of time that scheduler is able to count. E.g. if you choose 10000 as CH_CFG_ST_FREQUENCY (i.e. 10KHz) the lower limit to sleep time will be 100us (1/10KHz) with incertitude of 1 tick.
This is anyway unrelated to your problem. I think that there is a misconfiguration in the mcuconf.h with PLL sources/divider/multiplier. I suggest you to copy mcuconf from a default demo related to that MCU (i.e mcu conf of RT-STM32F767ZI-NUCLEO144 witch has the same clock tree)
If the PLL source is HSE take care to readapt also board files where the HSE frequency is defined. It should be now 25000000 (i.e. 25 MHz). This most likely would require to choose new divider/multiplier in comparison to default demo.
Ciao,
RM
RM
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: setting CH_CFG_ST_FREQUENCY
Hi,
Like Rocco explained CH_CFG_ST_FREQUENCY is only the system time resolution, it is not related to the CPU clock.
It must be chosen in a way that it can be obtained starting from the TIMx input frequency using the TIM 16bits prescaler and there must not be integer remainder to the division.
For example, if your TIM is clocked at 108MHz, you could not set a CH_CFG_ST_FREQUENCY of 1000 because 108000000/1000 = 108000, which is out of range.
Giovanni
Like Rocco explained CH_CFG_ST_FREQUENCY is only the system time resolution, it is not related to the CPU clock.
It must be chosen in a way that it can be obtained starting from the TIMx input frequency using the TIM 16bits prescaler and there must not be integer remainder to the division.
For example, if your TIM is clocked at 108MHz, you could not set a CH_CFG_ST_FREQUENCY of 1000 because 108000000/1000 = 108000, which is out of range.
Giovanni
-
- Posts: 3
- Joined: Mon Feb 04, 2019 6:17 pm
Re: setting CH_CFG_ST_FREQUENCY
Hi,
Thank you both for your advice I think i understand the use of CH_CFG_ST_FREQUENCY now.
I have reset the CH_CFG_ST_FREQUENCY and am going through the dividers in the mcuconf.h. I used the mcuconf file you suggested Rocco as a base and modified it for the change in oscillator (and posted it below) but I am still seeing a significant timing error when running the following code
or
the pulse width is 5us. Am i using the wrong macro for calculating the ms to cycles?
Cheers
Simon
Thank you both for your advice I think i understand the use of CH_CFG_ST_FREQUENCY now.
I have reset the CH_CFG_ST_FREQUENCY and am going through the dividers in the mcuconf.h. I used the mcuconf file you suggested Rocco as a base and modified it for the change in oscillator (and posted it below) but I am still seeing a significant timing error when running the following code
Code: Select all
for(;;)
{
palToggleLine(LINE_STM_LED2);
osalSysPolledDelayX(TIME_MS2I(10));
}
or
Code: Select all
for(;;)
{
palToggleLine(LINE_STM_LED2);
osalSysPolledDelayX(OSAL_MS2I(10));
}
the pulse width is 5us. Am i using the wrong macro for calculating the ms to cycles?
Cheers
Simon
Code: Select all
/*
* Board oscillators-related settings.
*/
#if !defined(STM32_LSECLK)
#define STM32_LSECLK 32768U
#endif
#define STM32_LSEDRV (3U << 3U)
#if !defined(STM32_HSECLK)
#define STM32_HSECLK 25000000U
#endif
/*
* HAL driver system settings.
*/
#define STM32_NO_INIT FALSE
#define STM32_PVD_ENABLE FALSE
#define STM32_PLS STM32_PLS_LEV0
#define STM32_BKPRAM_ENABLE FALSE
#define STM32_HSI_ENABLED TRUE
#define STM32_LSI_ENABLED TRUE
#define STM32_HSE_ENABLED TRUE
#define STM32_LSE_ENABLED FALSE
#define STM32_CLOCK48_REQUIRED TRUE
#define STM32_SW STM32_SW_PLL
#define STM32_PLLSRC STM32_PLLSRC_HSE
#define STM32_PLLM_VALUE 25
#define STM32_PLLN_VALUE 432
#define STM32_PLLP_VALUE 2
#define STM32_PLLQ_VALUE 9
#define STM32_HPRE STM32_HPRE_DIV1
#define STM32_PPRE1 STM32_PPRE1_DIV4
#define STM32_PPRE2 STM32_PPRE2_DIV2
#define STM32_RTCSEL STM32_RTCSEL_LSI
#define STM32_RTCPRE_VALUE 25
#define STM32_MCO1SEL STM32_MCO1SEL_HSI
#define STM32_MCO1PRE STM32_MCO1PRE_DIV1
#define STM32_MCO2SEL STM32_MCO2SEL_PLLI2S
#define STM32_MCO2PRE STM32_MCO2PRE_DIV2
#define STM32_I2SSRC STM32_I2SSRC_OFF
#define STM32_PLLI2SN_VALUE 200
#define STM32_PLLI2SP_VALUE 4
#define STM32_PLLI2SQ_VALUE 4
#define STM32_PLLI2SR_VALUE 4
#define STM32_PLLI2SDIVQ_VALUE 2
#define STM32_PLLSAIN_VALUE 192
#define STM32_PLLSAIP_VALUE 4
#define STM32_PLLSAIQ_VALUE 4
#define STM32_PLLSAIR_VALUE 4
#define STM32_PLLSAIDIVQ_VALUE 2
#define STM32_PLLSAIDIVR_VALUE 2
#define STM32_SAI1SEL STM32_SAI1SEL_OFF
#define STM32_SAI2SEL STM32_SAI2SEL_OFF
#define STM32_LCDTFT_REQUIRED FALSE
#define STM32_USART1SEL STM32_USART1SEL_PCLK2
#define STM32_USART2SEL STM32_USART2SEL_PCLK1
#define STM32_USART3SEL STM32_USART3SEL_PCLK1
#define STM32_UART4SEL STM32_UART4SEL_PCLK1
#define STM32_UART5SEL STM32_UART5SEL_PCLK1
#define STM32_USART6SEL STM32_USART6SEL_PCLK2
#define STM32_UART7SEL STM32_UART7SEL_PCLK1
#define STM32_UART8SEL STM32_UART8SEL_PCLK1
#define STM32_I2C1SEL STM32_I2C1SEL_PCLK1
#define STM32_I2C2SEL STM32_I2C2SEL_PCLK1
#define STM32_I2C3SEL STM32_I2C3SEL_PCLK1
#define STM32_I2C4SEL STM32_I2C4SEL_PCLK1
#define STM32_LPTIM1SEL STM32_LPTIM1SEL_PCLK1
#define STM32_CECSEL STM32_CECSEL_LSE
#define STM32_CK48MSEL STM32_CK48MSEL_PLL
#define STM32_SDMMC1SEL STM32_SDMMC1SEL_PLL48CLK
#define STM32_SDMMC2SEL STM32_SDMMC2SEL_PLL48CLK
#define STM32_SRAM2_NOCACHE FALSE
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: setting CH_CFG_ST_FREQUENCY
Hi,
Note that osalSysPolledDelayX() uses a different type, the delay is measured in clock cycles because it uses a monotonic counter increased by the CPU clock. The right macro is OSAL_MS2RTC().
You should use it when you need very accurate and very short delays.
Giovanni
Note that osalSysPolledDelayX() uses a different type, the delay is measured in clock cycles because it uses a monotonic counter increased by the CPU clock. The right macro is OSAL_MS2RTC().
You should use it when you need very accurate and very short delays.
Giovanni
-
- Posts: 3
- Joined: Mon Feb 04, 2019 6:17 pm
Re: setting CH_CFG_ST_FREQUENCY
Thanks Giovanni,
Just found and tested that macro and its working as expected!
Thank you for your help
Simon
Just found and tested that macro and its working as expected!
Thank you for your help
Simon
Who is online
Users browsing this forum: Baidu [Spider] and 3 guests