AN3140

Scenario with slow CNT_Clk and fast READ_Clk

Doc ID 16997 Rev 1

7/14

3

Scenario with slow CNT_Clk and fast READ_Clk

In certain cases, for example when the timer is used by an operating system to generate the

system tick, the CNT_Clk (after prescaling) is usually much slower than READ_Clk. For

example, let’s suppose you need to generate a tick every 10 ms; the GPT with a clock

source of 48 MHz might be programmed using a ‘/32’ internal prescaler and a counter equal

to 15000.

This results in a great number (around 60) READ_Clk ‘sampling cycles’ for every single

CNT_Clk cycle. Or, in other words, CNT_Clk is about 60 times slower than READ_Clk.

Figure 4.

CNT_Clk at low frequency

Let’s see what happens if the CPU does three consecutive read operations instead of a

single one. Since the bit instability lasts much less than the CNT_Clk time period, we can

say that, out of 3 READ_Clk edges, only one will ever fall into the bit instability window. The

other two are stable.

Moreover, since CNT_Clk is about 60 times slower than READ_Clk, the two stable read

operations return counter values that differ by 1 in the worst case, which is when there is a

CNT_Clk rising edge between the first and third read operations. Of course, interrupts

should be disabled during the reads.

So, reading three times the counter and discharging the unstable value (if any) is a valid

workaround that can be used for all GPTs of SPEAr3xx in similar scenarios.

In general, this workaround is valid when the minimum period of CNT_Clk is greater than 3

times the read_cycle_time. The read_cycle_time depends on the CPU frequency, and also

on the way the reads are implemented, so they should be carefully evaluated.

READ_Clk

(PCLK == 83MHz)

CNT_Clk

(48MHz/32 == 1.5 MHz)

Bit_N

t0

t1

t2

state

stable state. Samples are assumed

to happen every 3 READ_Clk cycles.