STM32F10x tick rate 1/2 speed

ajcurtis84 wrote on Tuesday, February 02, 2016:

Hello,
I am having difficulties with timers and vTaskDelay() with the STM32F processor. It appears that delays are about 2X the programmed rate.

I created a very simple task that delays for 4 seconds and reports the actual number of elapsed ticks. The ticks are correct but the actually delay is around 8 seconds.

Sample code:

 	TickType_t start_tick;
 	TickType_t end_tick;
 	do {
 		start_tick = xTaskGetTickCount();
 		vTaskDelay(4000);
 		end_tick = xTaskGetTickCount();
 		trace_printf("msec2ticks:%u ticks\n", (uint16_t)(end_tick-start_tick));
 	}
 	while (pdTRUE);

Originally I thought this was a problem in 8.2.3, however I back ported to 8.2.0 and received the same results.

The only other change is the trace output configuration. Changed:

#undef OS_USE_TRACE_SEMIHOSTING
#define OS_USE_TRACE_ITM

Has anyone else had this issue?

TIA

ajcurtis84 wrote on Tuesday, February 02, 2016:

Here is some more information:

  1. Created a BlinkyLED application from the Eclipse/GNUARM plugin. Removed all the LED related code and used the simple timer routines. These worked as expected.
  2. Copied the STM “system” code from the BlinkyLED project to the FreeRTOS test program. Same problem with the tick rate being 1/2 rate.
  3. Compared the RCC register configuration between the two programs. They were the SAME!

RCC:CR = 0x00015283
RCC:CSR = 0x1C000000
RCC:AHBENR = 0x00000014

Can anyone provide further insight or recommendations?

Thanks

heinbali01 wrote on Tuesday, February 02, 2016:

Hi Allen,

What is your program printing:

msec2ticks:4000 ticks

or

msec2ticks:8000 ticks

?

I suppose that configTICK_RATE_HZ is defined as 1000 ?

Wat does sysclk_get_cpu_hz() return? Is the CPU really running at the expected frequency?

Regards.

rtel wrote on Tuesday, February 02, 2016:

When I read:

I created a very simple task that delays for 4 seconds and reports the actual number of elapsed ticks. The ticks are correct but the actually delay is around 8 seconds.

When reading this my thought was, if the delay is correct in the number of ticks, but the time is different, then this is simply a case of the CPU clock running at a different frequency to that which you think it is. Perhaps configCPU_CLOCK_HZ is wrong. However, then you write:

#undef OS_USE_TRACE_SEMIHOSTING
#define OS_USE_TRACE_ITM

you mention semihosting. Are you using semihosting? If so, don’t, it will mess up your timing as it will stop the CPU while outputing to the host - and that might be the problem you are seeing.

Regards.

ajcurtis84 wrote on Tuesday, February 02, 2016:

Hello,

Thank you for the reply. No, I am not using SEMIHOSTING. Originally I was but it was causing all sorts of problems.

My BSP does not have the sysclk_get_clk_hz() function so I inserted the following code.

  trace_printf("System clock: %u Hz\n", SystemCoreClock);

	RCC_ClocksTypeDef clock;
	RCC_GetClocksFreq(&clock);
	trace_printf("SYSCLK=%ld,HCLK=%ld,PCLK1=%ld,PCLK2=%ld,ADCCLK=%ld\n",
			clock.SYSCLK_Frequency,
			clock.HCLK_Frequency,
			clock.PCLK1_Frequency,
			clock.PCLK2_Frequency,
			clock.ADCCLK_Frequency);

This is the output

System clock: 8000000 Hz
SYSCLK=8000000,HCLK=8000000,PCLK1=8000000,PCLK2=8000000,ADCCLK=4000000

Based on this I debugged the SystemInit() function and determined that HSE never becomes ready. It looks like the oscillator isn’t working?

Thank you for pointing me in the right direction.