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?

[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

[janvb]

I regret to see that nrf52 support is winding down and that these chips are  apparently no longer recommended for new designs although this is nowhere indicated on the Nordic Semiconductor website.

[Kenneth]

Hello,

Maybe my answer came out a bit wrong, there is nothing wrong with developing with the nRF52-series, if it's critical for your application to resolve your observation I can try to make a case about it internally.

Kenneth

[janvb]

Hi  Kenneth, I would really appreciate further investigation. 

The application involves a trailing edge dimmer. The effect of the bug I described is that the light will show a flash before going dark when being dimmed lower. 

[Kenneth]

Hi,

I think you are looking at the wrong place. The times I have seen someone mention "flash before going dark", the problem occurs at the time the PWM reach the max or min value, at this time the PWM driver will normally stop and switch to steady high or low output as a normal gpio (since it doesn't make sense to run it as a PWM at this stage). I have seen number of times that there are small errors during this transition in the PWM driver; disable/enable PWM and configure output high/low is done in the wrong order, thereby for a short period causing inverted output. At least that is where I would have started looking.

Kenneth