ChibiOS Free Embedded RTOS

I am using the default files from testhal/UART for STM32F103 and having some difficulty understanding how this works. on ChibiOS 3.0.0

1.) The default demo should provide a system clock frequency of 72Mhz right?
2.) Changing STM32_PLLSRC to STM32_PLLSRC_HSI, the delay seems to be doubled



On an oscilloscope, the waveform shows a 500ms on/off waveform. I thought that my external crystal is causing the problem but digging in to RM0008 shows that the HSE is divided to 2 before being fed to the PLL. Changing STM32_PLLXTPRE_DIV1 to STM32_PLLXTPRE_DIV2 for STM32_PLLSRC_HSE gave me a 250ms on/off waveform as I should have expected.

3.) Changing the STM32_PLLMUL_VALUE to a lower value seems to create a faster delay. (eg 250ms becomes 150ms) Shouldn't the delay always be the same independent of the clock frequency?

Looking forward to your replies.

Demos for F1 set clock to 72MHz. Clock is affected by settings in mcuconf.h AND HSE frequency in board.h.

Giovanni

My HSE is 8Mhz which is the same as the internal RC.

How about question 2 and 3? Why is chThdSleepMilliseconds() affected by clock settings? Should it not be independent of this setting?

Also, a lower STM32_PLLMUL_VALUE give me a slower clock, hence a longer delay instead of something faster that i have seen?

Timing should not be affected by clock, if chthdSleeMilliseconds() gives you wrong timings then there is an error somewhere. In general all settings in mcuconf.h come from the clock tree shown on the STM32 RM and should behave according to the RM.

If you use an STM32F1 make sure to start from a demo running on an F1.

Giovanni

If you make chibios think your CPU runs at 10MHz (just a number, to make my calculations easier), then when you sleep for 250ms chibios will count 2500000 cycles and restart your process. If in fact your CPU runs at only 5MHz, that will take 500 instead of 250ms.

When you say "change" and you're poking directly into the clock control registers, then that is exactly what will happen: chibios does not know you changed the clock.

Correct, clocks are calculated at compile time so run time changes are not taken into account automatically.

Giovanni

What rew said makes sense and is what i am expecting. Using the UART demo in testhal,

Changing to use:



Gave me a faster delay than:





Can someone explain to me why this is happening compared to what rew explained? I would expect that the chThdSleepMilliseconds(1000); gives me a 1second delay than a less than 1second delay. Is there a bug somewhere?

It is possible you are violating some VCO limit and the actual frequency is higher than the calculated one.

Giovanni