Timer compare not matching after rewriting CC register

[Michael]

Had an interresting issue that we have resolved, but we're trying to understand...

We had a timer (TIMER2) running and matching towards CC[3] every 500us. This match results in the ISR being called. In the sISR we updated CC[2] to generate another match to use a GPIOTE to create a pulse.

When we used it this way - we only got very sporadic matches from CC[2]. However, when we do not update CC[2] we get matches every time.

Is there some sort of "protection" that makes so that the match does not happen within a certain amount of time after writing a CC register?

[Kenneth]

Hi,

Can't think of any no, could be interesting if you after writing to CC[2] do a timer capture to CC[4] and check if it's value is below or above CC[2].

Kenneth

[Michael]

By design the CC[2] is written to a value that is approx 100 less than CC[3] and being written to approx 300us before the desired match.

if we do not rewrite CC[2] at all, then it matches every time (to the value being set), But if setting it like;

 NRF_TIMER2->CC[2] = NRF_TIMER2->CC[3] - offset

In the ISR triggered by CC[3][ then it only happens sporadically.

[Kenneth]

Hello,

Any chance you could setup a small project for me to recreate it here? My first suggestion would be to update NRF_TIMER2->CC[2] from a static variable, and not rely on reading out the CC[3]. I know in the past there were some issues reading out the CC[] register, but I believed that was the RTC though, and possible nRF51-series.

Kenneth 

[janvb]

I have a similar problem with timer 3 of nrf52820.

I use ppi to clear a pin on CC[2] and to set on CC[3] . The timer is cleared (also through ppi) with a gpiote event on another pin. This event also creates on interrupt, and in the interrupt routine CC[3] is re-written. CC[2] is fixed on value 2. 

Everything works fine as long as CC[3] is written with value greater than 128. When a value below 128 is used, the output pins remains low for one timer cycle. It seems that CC[3] is missing a cycle. Next cycle every thing is OK again, even when values lower than 128 are written. 

The timer is running on 4MHz clock and the cycle time is 10ms (counter is approx. 40000 when cleared). 

[Kenneth]

Hello,

I will admit this is indeed interesting, and not something I have heard of before. I think we need to be a bit realistic on what we can investigate on a rather old chip. So unless something is failing like the original request, I think we just have to consider this the way it is by design. For new development I would encourage everyone to check out the nRF54L family of devices. Hope that make sense, though it could be this is relevant for the original poster here.

Kenneth