1ms HAL delay

richardaddy9 · ‎2017-10-16

Posted on October 16, 2017 at 17:14

Working with the STM32L052C8 using the HAL commands.

I'm using the 'HAL_Delay()' command which is meant to be a delay in ms but I'm measuring HAL_Delay(1); to be 15ms.

Checked with the data sheet and it says to have the Cortex System Timer at 4MHz which I have got by using Cubemx.

Any ideas would be greatly appreciated, Thanks.

waclawek.jan · ‎2017-10-16

Posted on October 16, 2017 at 20:12

if it's based on 1ms systick, the actual delay is anywhere between 0 and 1ms; with argument (5) it would be between 4 and 5ms etc.

Checked with the data sheet and it says to have the Cortex System Timer at 4MHz

Don't understand, give pointers.

JW

richardaddy9 · ‎2017-10-17

Posted on October 17, 2017 at 10:12

In the reference manual for the STM32L0 #12.2 it says about the Systick clock to be set to 4MHz, which is the Cortex System Timer in Cubemx. 2 images shown below.

So I set this to 4MHz and measured the HAL_Delay(1); but it measured as 15ms on a scope, instead of 1ms.

Thanks,

Richard

AvaTar · ‎2017-10-17

Posted on October 17, 2017 at 10:22

I think there is a misunderstanding on your side.

The ref manual means here that this SysTick calibration value (4000) is calibrated for a system clock of 4MHz.

4MHz / 4000 = 1kHz => 1ms

SysTick itself is just a 24-bit counter that works on the core clock.

If the SysTick is not what you expect, the core clock is most probably not what you think.

Don't know (or care) what Cube does here, sorry.

waclawek.jan · ‎2017-10-17

Posted on October 17, 2017 at 10:30

The systick calibration value is content of a read-only register, STK_CALIB, and is just a hint (btw. if it's really 4000

https://community.st.com/0D50X00009XkaB4SAJ

, but I am not surprised and it is really of no importance). You can set the systick to any division rate in STK_RVR. Read chapter 4.4. of PM0

Cube surely has some mechanism to set this, but I don't Cube. Cube has some documentation so you can try to find it there. Cube is open source so you can look it up. And you can always look in the debugger at the actual STK_RVR setting.

But I repeat, with a 1ms granularity primary source, 1-tick loopdelay may last anywhere between 0 and 1ms. Try a longer one and divide the result for more precision.

JW

waclawek.jan · ‎2017-10-17

Posted on October 17, 2017 at 10:35

The ref manual means here that this SysTick calibration value (4000) is calibrated for a system clock of 4MHz.

4MHz / 4000 = 1kHz => 1ms

That would be true, wouldn't systick count from (reload-value -1), but it does not.

When enabled, the timer counts down from the reload value to zero, reloads (wraps to) the

value in the SYST_RVR on the next clock cycle, then decrements on subsequent clock

cycles.

To generate a multi-shot timer with a period of N processor clock cycles, use a RELOAD

value of N-1. For example, if the SysTick interrupt is required every 100 clock pulses, set

RELOAD to 99.

I ranted already, see link in my previous post.

JW

AvaTar · ‎2017-10-17

Posted on October 17, 2017 at 11:22

That would be true, wouldn't systick count from (reload-value -1), but it does not.

You are correct.

But with 15ms instead of 1ms, there is something else substantially wrong.

Cube surely has some mechanism to set this, but I don't Cube.

As said, +1.

I used to have such large SysTick 'deviations' when the clock setup was incorrect.

Which should be easy to find.