32F4 - a timer without interrupts - CYCCNT

[peter-h]

This seems to be a free running 32 bit counter, which can be polled at any time. So it could be used to implement a timeout on some loop.

A search of my project, including all the HAL stuff, finds no reference to it except definitions in various .h files. So it doesn't appear to get started anywhere.

This https://stackoverflow.com/questions/42246125/how-to-get-time-intervals-on-stm32 shows a simple usage example but how do I guard against the 32 bit rollover? The timeouts I want are only milliseconds, but the counter will still sometimes roll over during that. I don't want to be resetting the counter in case another bit of code is using it.

Also searching (e.g. https://developer.arm.com/documentation/ddi0337/e/System-Debug/DWT/Summary-and-description-of-the-DWT-registers?lang=en#BABFDDBA) suggests that debuggers may be resetting it to zero, etc.

[lucazader]

As you may have stumbled on the ARM documentation, "When the counter overflows it wraps to zero, transparently".
I would suggest this makes it not ideal for your purposes.

A better method would be to either use the systick and take timestamps, or timeout times based on this.
If you need a faster timer than this then i would suggest creating a 1us tick timer based on one of the other timers in the system.
I do this quite often. Set the timer to count at a 1us tick rate. Interrupt on overflow and increment a an overflow counter.
Then implement a get_usec() function that returns the time since program start in us. (I tend to use a uint64_t for this as a 32 bit counter would overflow at ~71 Mins)

Code: [Select]

volatile uint64_t hrt_overflows = 0;
void TIMER_IRQN_HANDLER(void) // correct irq hander for your timer
{
    __HAL_TIM_CLEAR_IT(&htim6, TIM_IT_UPDATE);
    ++hrt_overflows;
}

uint64_t get_tick_usec(void)
{
    return  (hrt_overflows << 16) + htim6.Instance->CNT;
}
Very low overhead, as it will only interrupt once every 65ms

[peter-h]

In my project, initially HAL based, systick is heavily referenced within the STM code (and is used by FreeRTOS), and HAL_GetTick is also heavily referenced. Systick is a 1kHz interrupt. HAL_GetTick is

Code: [Select]

/**
  * @brief Provides a tick value in millisecond.
  * @note This function is declared as __weak to be overwritten in case of other
  *       implementations in user file.
  * @retval tick value
  */
__weak uint32_t HAL_GetTick(void)
{
  return uwTick;
}
and uwTick seems to be point to nothing meaningful

Code: [Select]

/* Private macro -------------------------------------------------------------*/
/* Private variables ---------------------------------------------------------*/
/** @addtogroup HAL_Private_Variables
  * @{
  */
__IO uint32_t uwTick;
uint32_t uwTickPrio   = (1UL << __NVIC_PRIO_BITS); /* Invalid PRIO */
HAL_TickFreqTypeDef uwTickFreq = HAL_TICK_FREQ_DEFAULT;  /* 1KHz */
so it may be doing nothing.

AIUI, regarding 32 bit rollover, if you read the reg into uint32_t, then subtraction always works even if it has overflowed.

Yes one could also read some timer. I am using TIM6 to generate a 1kHz interrupt for various things. And a debugger would not mess with that.

[lucazader]

You mention FreeRTOS in your reply.
If you are using freertos then you should probably be using the freertos based timers, delays and tick counts.
E.G. xTaskGetTickCount() (https://www.freertos.org/a00021.html#xTaskGetTickCount)

[peter-h]

FreeRTOS needs interrupts (obviously) and using any of that would make the code non-portable to a different scenario.

Hence reading the CPU cycle count seems a good option. It just seems curious that this counter was never started...

[DavidAlfa]

As long as you read it at least twice the rate than it overflows, and also check if it's smaller than the last time (It rolled over), it will be ok.
For 48MHz it's every 89 seconds, for 72MHz is 59 seconds and so on, you have plenty of time to check it.

Being free running with no interrupts, you have to make a handler and call in from the main loop, so it checks CYCCNT.
You must store the last CYCNT value, compare with the new one, increase the millisecond counter every FCY/1000.
Normally you woud find the difference doing last-new, but if CYCCNT is lower than the previous value, you know it overflowed, so on this case you must do (2^32-old)+CYCCNT.
And you only update the old value when increasing the millisecond counter.

[westfw]

https://github.com/adafruit/ArduinoCore-samd/blob/master/cores/arduino/delay.c#L64


dwt cyccnt timer used for delayMicroseconds() in arduino since 2019 on Adafruit samd51 boards

[langwadt]

if you use signed numbers and only have a maximum of one overflow between two timestamps, the difference between to timestamps still come out correct

[DavidAlfa]

It's perfectly valid as long as your main loop doesn't get blocked somewhere for too long.
I think this would do ok, I might have missed something.

Code: [Select]

#define SYS_FCY  48000000                         // System clock in Hz
uint32_t sys_ms;                                  // Variable for storing system milliseconds
uint32_t last_cnt;                                // Variable for storing previous CYCCNT value

uint32_t get_ms(void){                            // Read current time
  return sys_ms;
}

void reset_timer(void){                           // Reset timer
  sys_ms = 0;
  last_cnt = 0;
  DWT->CYCCNT = 0;
}

void handle_Timer(void){                          // Update system time
  uint32_t diff, current = DWT->CYCCNT;
 
  if(current>=last_cnt){                          // No rollover
    diff=current-last-cnt;
  }
  else{                                           // Rollover
    diff=current + (0xFFFFFFFF-last_cnt);
  }
 
  if(diff>=(SYS_FCY/1000)){                       // If diff >= FCY/1000 (1ms)
    sys_ms++;                                     // Increase ms counter
    last = current - (diff-(SYS_FCY/1000));       // update last, not to current, but current-(diff-(FCY/1000)) to keep the remainder for the next millisecond step
  }
}


int main(void){
  ...
  init, etc
  ...
  while(1){
    ...
    ...
    handle_Timer();
  }
}


[peter-h]

Looking at the above, and the Github link further up, it looks like the simplest way one could do a timeout is like this:

CYCCNT  initialisation (at CPU startup only):

Code: [Select]

#define CoreDebug_DEMCR_TRCENA_Msk         (1UL << 24U)
#define DWT_CTRL_CYCCNTENA_Msk             0x1UL

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CYCCNT = 0;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;

Code: [Select]

int32_t start_time = DWT->CYCCNT;
int32_t max_count = 10000;  // probably this counts CPU clocks / 4... need to look it up

do
{
   whatever stuff could take too long
   ...
   ...
   ...
}
while ( (DWT->CYCCNT < (start_time+max_count)) || (some other condition) );
and using signed int32 the overflow condition is not an issue.

I recall a post here recently saying that using unsigned avoids the overflow condition but I can't work that out.

[DavidAlfa]

Unless "whatever stuff could take too long" gets stuck and never reaches the while check
And yes it counts CPU clock, you need to convert time to clocks.

[peter-h]

Yes

Just compiled this

Code: [Select]

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CYCCNT = 0;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;

int32_t start_time = DWT->CYCCNT;
int32_t max_count = 1000000000;

do
{
debug_puts("hello\n");  // ITM data console version of "puts()"
hang_around(1000);  // dumb wait for 1000ms (uses inline asm)
}
while (DWT->CYCCNT < max_count);

and I see six "hello"s, which is spot on for 168MHz

But this does not work

Code: [Select]


        CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CYCCNT = 0;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;

int32_t start_time = DWT->CYCCNT;
max_count = 168000000;  // 168M = 1 sec

do
{
debug_puts("counting...\n");
start_time = DWT->CYCCNT;
while ( DWT->CYCCNT < (start_time+max_count) ) {}
}
while (true);


I get one "counting..." and then nothing. The comparison clearly doesn't work.

It works with uint32_t but also falls over after some tens of seconds. So what is the secret of the code which handles overflow inherently?

[DavidAlfa]

langwadt, where's that int magic? I don't see anything else than problems.
The function might fail because the int32_t becomes negative (2147483646,  2147483647 -> -2147483648, -2147483647...)

The check would no longer be valid if CYCCNT is still positive but adding max_count causes int overflow, becoming negative.

ex:
CYCCNT = 0x7FFFD8EF (2147473647)
2147473647+168000000 = 0x8A0352EF (-1979493649)

while ( 2147483647 <  -1979483649 )


So in the end it's the same thing than with plain unsigned, but adding another headache.

Add more checks, or just don't run a while loop like that, clearing the counter after each loop:

Code: [Select]

max_count = 168000000;  // 168M = 1 sec
do
{
                DWT->CYCCNT=0;
debug_puts("counting...\n");
while ( DWT->CYCCNT < max_count);
}
while (true);


[peter-h]

This post says otherwise
https://www.eevblog.com/forum/microcontrollers/32f417-spi-master-mode-1-byte-case-mystery/msg3637762/#msg3637762

and this seems to be the ST HAL implementation - example

Code: [Select]

  tickstart = HAL_GetTick();

  while(__HAL_FLASH_GET_FLAG(FLASH_FLAG_BSY) != RESET)
  {
    if(Timeout != HAL_MAX_DELAY)
    {
      if((Timeout == 0U)||((HAL_GetTick() - tickstart ) > Timeout))
      {
        return HAL_TIMEOUT;
      }
    }
  }

[langwadt]

langwadt, where's that int magic? I don't see anything else than problems.
The function might fail because the int32_t becomes negative (2147483646,  2147483647 -> -2147483648, -2147483647...)

The check would no longer be valid if CYCCNT is still positive but adding max_count causes int overflow, becoming negative.

ex:
CYCCNT = 0x7FFFD8EF (2147473647)
2147473647+168000000 = 0x8A0352EF (-1979493649)

while ( 2147483647 <  -1979483649 )

it's a bit of a mind bender, but when things get truncated is important

try

uint32_t start = CYCCNT;
while((CYCCNT-start) < max_count) ;

[westfw]

uint32_t start = CYCCNT;
while((CYCCNT-start) < max_count) ;

Handling overflow of counters, whether they are cycle counters or millisecond counters, is pretty well understood, and the above is the correct way to do it.


Consider an 8bit counter where you want to time 10 counts, and start at t=250 (an unsigned 8bit quantity, of course.)
After 5 ticks, 255-250 = 5, which is exactly what you expect.  At 6 ticks the counter has overflowed to 0, and you have 0-250 = 6, once you truncate to 8bits.  After 10 ticks, t = 4, and 4-250=10, which is just right.  Make sure you comparison happens in the same word size as your variables, which may not be the case in languages like C with integer promotion:

Code: [Select]

(gdb) print (unsigned char)(4 - 250)
$3 = 10 '\n'
(gdb) print (unsigned char)6 - (unsigned char)250
$4 = -244

[SiliconWizard]

This is basic modular arithmetic. Of course you need to use unsigned integers for the operations to be correct. Subtracting works as expected even when there's an overflow - due to C (as would be done in pure assembly) doing roll-over arithmetic, which is just modulo 2^N, where N is the integer bit width.

Of course, the subtraction stops being correct though if the counter has rolled over more than once.

[langwadt]

This is basic modular arithmetic. Of course you need to use unsigned integers for the operations to be correct. Subtracting works as expected even when there's an overflow - due to C (as would be done in pure assembly) doing roll-over arithmetic, which is just modulo 2^N, where N is the integer bit width.

Of course, the subtraction stops being correct though if the counter has rolled over more than once.

I'll have think about it but I don't think it needs to be unsigned

[westfw]

due to C (as would be done in pure assembly) doing roll-over arithmetic

I think it's more the CPUs themselves than the language.  Though I suppose that you could somehow use saturating arithmetic or cause exceptions...

I'll have think about it but I don't think it needs to be unsigned

The math doesn't care, but the comparison needs to know whether the result is signed or not.  Otherwise -1 is less than 1.  This is more obvious on CPUs that have different conditional branch instructions for signed vs unsigned.  Like BRLO vs BRLT on AVR.  One of them checks the carry bit, and one checks (HIGHBIT xor OVERFLOW) bits.

[Nominal Animal]

Note that the ARM cycle counter (CYCCNT) must be enabled in the DWT; it may not be enabled by default.

In C, and on all 32-bit ARM arches, given uint32_t  before, after;
    after - before
is equivalent to
    (uint32_t)(after - before)
and is nonnegative.  In the case where before > after, the value follows modulo 2³² arithmetic, and is exactly 2³²-before+after.

No tricks needed, no ifs needed.  If you know before occurred before after, and the difference between the two was less than 2³² cycles, then after - before always yields the correct number of cycles in between, even when before > after, due to modulo arithmetic rules.  And those are enforced both by GCC/Clang, and the ARM hardware.

Signed arithmetic differs, except that both GCC and Clang on all 32-bit arches always implement twos complement modulo arithmetic (with representable values ranging from -2³¹ to 2³¹-1, inclusive).  You can think of it as adding or subtracting 2³² to/from the result, until it is within the representable range.  In reality, the overflow is either lost, or saved in a flag.  GCC and Clang do provide integer overflow built-ins as extensions to C and C++, if you do want to detect signed or unsigned overflow.

If you want to use 64-bit cycle counter, you can use for example

Code: [Select]

static volatile word64  cycle_counter;

static inline uint64_t  cycles(void)
{
    word64  old_state, new_state;

    old_state = cycle_counter;

    new_state.u32_lo = ARM_DWT_CYCCNT;  // or DWT->CYCCNT, dunno
    new_state.u32_hi = old_state.u32_hi + (new_state.u32_lo < old_state.u32_lo);

    cycle_counter = new_state;  // TODO: Make this atomic!

    return new_state.u64;
}
where the word64 type is an union,

Code: [Select]

#include <stdint.h>

typedef union {
    uint64_t  u64;
    int64_t   i64;
#ifdef  __BYTE_ORDER__-0 == __ORDER_LITTLE_ENDIAN__-0
    struct {
        uint32_t  u32_lo;
        uint32_t  u32_hi;
    };
    struct {
        uint32_t  i32_lo;
        uint32_t  i32_hi;
    };
#elif __BYTE_ORDER__-0 == __ORDER_BIG_ENDIAN__-0
    struct {
        uint32_t  u32_hi;
        uint32_t  u32_lo;
    };
    struct {
        uint32_t  i32_hi;
        uint32_t  i32_lo;
    };
#else
#error Unknown byte order
#endif
}  word64;
Type punning via an union like this is explicitly allowed in C.  The __BYTE_ORDER__ check is needed (this is written for GCC and Clang, other compilers may export other macros) because the byte order (endianness) of the target architecture determines whether the high or low 32 bits of the combined 64-bit value is stored first.  You could use bit shifts for portable code, but cycle counting (CYCCNT and similar, for example __builtin_ia32_rdtsc() on x86 and x86-64) itself is already something very hardware-dependent; I believe that in this particular case, the type punning approach is better/warranted.

If the cycle_counter = new_state; assignment was atomic, or done while interrupts disabled on a single-core system, then it would be safe to call cycles() at any point, even in an interrupt context.  As it is written now, it is not reliable if it is ever called in an interrupt context, because there is a tiny possibility of the interrupt occurring exactly in the middle of the 64-bit assignment, since it is done using two 32-bit assignments.
If you cannot make it atomic (noting that it is not enough to unconditionally disable then enable interrupts, because it might be called with interrupts already disabled), then there are ways to rewrite the function to do it anyway (because the cycle counter grows upward, and we can more or less assume that any interrupts take less than 2³⁰ or so cycles), but it gets a bit complicated and much less robust.

The "odd" part in it, + (new_state.u32_lo < old_state.u32_lo), simply adds 1 if the low 32 bits wrap around.  In C, logical expressions evaluate to 1 if true, and to zero if false.  We just need to ensure the order of operations using the parentheses, and the compiler will handle the details for us.

Finally, note that you need to call cycles() at least once per every 2³² cycles, so that CYCCNT wraparound is correctly detected.  Perhaps in SysTick, or some other periodic timer you use.

[langwadt]

Note that the ARM cycle counter (CYCCNT) must be enabled in the DWT; it may not be enabled by default.

In C, and on all 32-bit ARM arches, given uint32_t  before, after;
    after - before
is equivalent to
    (uint32_t)(after - before)
and is nonnegative.  In the case where before > after, the value follows modulo 2³² arithmetic, and is exactly 2³²-before+after.

No tricks needed, no ifs needed.  If you know before occurred before after, and the difference between the two was less than 2³² cycles, then after - before always yields the correct number of cycles in between, even when before > after, due to modulo arithmetic rules.  And those are enforced both by GCC/Clang, and the ARM hardware.

Signed arithmetic differs, except that both GCC and Clang on all 32-bit arches always implement twos complement modulo arithmetic (with representable values ranging from -2³¹ to 2³¹-1, inclusive).  You can think of it as adding or subtracting 2³² to/from the result, until it is within the representable range.  In reality, the overflow is either lost, or saved in a flag.  GCC and Clang do provide integer overflow built-ins as extensions to C and C++, if you do want to detect signed or unsigned overflow.

If you want to use 64-bit cycle counter, you can use for example

Code: [Select]

static volatile word64  cycle_counter;

static inline uint64_t  cycles(void)
{
    word64  old_state, new_state;

    old_state = cycle_counter;

    new_state.u32_lo = ARM_DWT_CYCCNT;  // or DWT->CYCCNT, dunno
    new_state.u32_hi = old_state.u32_hi + (new_state.u32_lo < old_state.u32_lo);

    cycle_counter = new_state;  // TODO: Make this atomic!

    return new_state.u64;
}
where the word64 type is an union,

Code: [Select]

#include <stdint.h>

typedef union {
    uint64_t  u64;
    int64_t   i64;
#ifdef  __BYTE_ORDER__-0 == __ORDER_LITTLE_ENDIAN__-0
    struct {
        uint32_t  u32_lo;
        uint32_t  u32_hi;
    };
    struct {
        uint32_t  i32_lo;
        uint32_t  i32_hi;
    };
#elif __BYTE_ORDER__-0 == __ORDER_BIG_ENDIAN__-0
    struct {
        uint32_t  u32_hi;
        uint32_t  u32_lo;
    };
    struct {
        uint32_t  i32_hi;
        uint32_t  i32_lo;
    };
#else
#error Unknown byte order
#endif
}  word64;
Type punning via an union like this is explicitly allowed in C.  The __BYTE_ORDER__ check is needed (this is written for GCC and Clang, other compilers may export other macros) because the byte order (endianness) of the target architecture determines whether the high or low 32 bits of the combined 64-bit value is stored first.  You could use bit shifts for portable code, but cycle counting (CYCCNT and similar, for example __builtin_ia32_rdtsc() on x86 and x86-64) itself is already something very hardware-dependent; I believe that in this particular case, the type punning approach is better/warranted.

If the cycle_counter = new_state; assignment was atomic, or done while interrupts disabled on a single-core system, then it would be safe to call cycles() at any point, even in an interrupt context.  As it is written now, it is not reliable if it is ever called in an interrupt context, because there is a tiny possibility of the interrupt occurring exactly in the middle of the 64-bit assignment, since it is done using two 32-bit assignments.
If you cannot make it atomic (noting that it is not enough to unconditionally disable then enable interrupts, because it might be called with interrupts already disabled), then there are ways to rewrite the function to do it anyway (because the cycle counter grows upward, and we can more or less assume that any interrupts take less than 2³⁰ or so cycles), but it gets a bit complicated and much less robust.

The "odd" part in it, + (new_state.u32_lo < old_state.u32_lo), simply adds 1 if the low 32 bits wrap around.  In C, logical expressions evaluate to 1 if true, and to zero if false.  We just need to ensure the order of operations using the parentheses, and the compiler will handle the details for us.

Finally, note that you need to call cycles() at least once per every 2³² cycles, so that CYCCNT wraparound is correctly detected.  Perhaps in SysTick, or some other periodic timer you use.

and it also  works for safely extending a counter (e.g. quadrature) that can count both ways, at regular intervals shorter than the wraparound
add the signed difference to a larger counter variable

[peter-h]

I remember, from decades ago, a shaft encoder front end using a Z80 and the Z80-CTC http://www.z80.info/zip/z80ctc.pdf which fed the two pulse trains to two 8-bit counters, and never lost track of the shaft position no matter when the CPU read the counters, provided it read them before they saw 256 pulses. I think we extracted the two values on a 10ms interrupt.

It came out from some appnote and neither myself nor anybody else understood how it worked, but it worked perfectly, and my then company made a fair bit of money out of selling it

I reckon this gets used in inertial nav systems too; they use optical encoders for zero friction.

[Nominal Animal]

If the pulse counters are directional as opposed to quadrature – i.e., counter A counts pulses clockwise, counter B counterclockwise, both counters increasing, then

Code: [Select]

static uint8_t  rot_inc_lo, rot_dec_lo, rot_hi;

static inline uint16_t  rotation(void)
{
    uint8_t  old_inc_lo = rot_inc_lo;
    uint8_t  old_dec_lo = rot_dec_lo;
    rot_inc_lo = read_counter_a();
    rot_dec_lo = read_counter_b();
    rot_hi += (rot_inc_lo < old_inc_lo);
    rot_hi -= (rot_dec_lo < old_dec_lo);
    return ((uint16_t)(rot_hi) << 8) | (uint8_t)(rot_inc_lo - rot_dec_lo);
}
which can look really odd unless you understand how it works.  Both A and B counters are increasing 8-bit counters, but their difference is the value sought for.  The high byte is incremented whenever the positive counter wraps around, and decremented whenever the negative counter wraps around.  (While the result is 16-bit, you can treat it either as unsigned or signed on a Z80, by just changing the function result type above.)

The logic here is exactly the same as my previous post, except that here we have two opposing counters whose difference is the desired state.

In Z80 assembly, you can leverage the fact that subtracting the previous 8-bit counter from the new value yields the difference (that can be added to the previous counter value), but also sets the carry flag (to indicate whether the high byte needs to be incremented/decremented).  I'm not sure if you'd need to disable interrupts for a couple of instructions (definitely not for more than a few instructions), but the code implementing similar logic as above would be a rather funky mix of IN, SUB, ADC, SBC, and LD Z80 instructions.  Without a comment describing the logic (perhaps in pseudocode), I'm pretty sure the assembly would be write-only code.

Several variants exist for quadrature logic, although I personally prefer the see-saw approach (each rising transition switches the interrupt between the two pins, and the direction depends on whether the other pin is high or low), since that gives the most robust reading (and no contact bounce issues).  That does generate an interrupt per pulse pair, and at varying time intervals when direction changes, but in my use cases that has not mattered at all.  (I do like tactile EC11 rotary encoders, especially the kind with the extra push switch, for human interfaces.)
I do believe you only need some Schmitt trigger inputs and simple logic to derive the separate increment/decrement pulses like above from quadrature logic.  For mechanical encoders I think contact bounce would be a bit problematic, but I guess that's how you did it back then for optical encoders? 

[peter-h]

It was all in assembler (c. 1980) but the bit I could never understand is how it worked given that it was obviously impossible to read the two counters atomically. There could easily be pulses happening betwen reading one and reading the other.

I don't have the circuit but yes there were a few gates before the CTC. The up/down direction was determined from the phase relationship of the two square waves.

The resemblance of this scheme to the CYCCNT topic is that it didn't matter if the counters wrapped around. Modular arithmetic. It was really elegant. But none of us ever understood it

[SiliconWizard]

I'll have think about it but I don't think it needs to be unsigned

The math doesn't care, but the comparison needs to know whether the result is signed or not.  Otherwise -1 is less than 1.  This is more obvious on CPUs that have different conditional branch instructions for signed vs unsigned.  Like BRLO vs BRLT on AVR.  One of them checks the carry bit, and one checks (HIGHBIT xor OVERFLOW) bits.

Exactly.
Note, as I said, that it works if the language you use allows it. Many, such as C, do, because they just implement 2^N modular arithmetic, which is cheapest on most common CPUs.
Of course, with languages that do not implement overflow as a simple "rollover" - either by saturating the result or generating an exception - this simple scheme won't work.

With a language such as ADA, you can do this using a "mod" type. Basic integers won't do.
For instance, for a 32-bit counter, you could define the following type:

Code: [Select]

type Counter32_t is mod 2**32;