Timer compare not matching after rewriting CC register

RE: Timer compare not matching after rewriting CC register

janvb — Sun, 04 Jan 2026 11:12:53 GMT

Happy new year! Wishing you all the best and also some spare time to look into this problem....

RE: Timer compare not matching after rewriting CC register

Kenneth — Mon, 01 Dec 2025 10:13:15 GMT

Not had a chance to try it yet.

Kenneth

RE: Timer compare not matching after rewriting CC register

janvb — Fri, 28 Nov 2025 14:20:39 GMT

Any success?

Jan

RE: Timer compare not matching after rewriting CC register

Kenneth — Tue, 25 Nov 2025 09:03:13 GMT

But I can try with a newer release later if you are not able to make it work.

Kenneth

RE: Timer compare not matching after rewriting CC register

Kenneth — Tue, 25 Nov 2025 08:54:55 GMT

Not really, you see we need to use the version it was released with:
https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/index.html

The following toolchains/devices have been used for testing and verification:
 
 - ARM: MDK-ARM version 5.25   
 - GCC: GCC ARM Embedded 9.2020-q2.major
 - IAR: IAR Workbench 7.80.4
 - SES: SES 5.42a

Kenneth

RE: Timer compare not matching after rewriting CC register

janvb — Tue, 25 Nov 2025 07:41:04 GMT

Can you try updating SES? You are using an old version of SES, I am using version V8.24.

RE: Timer compare not matching after rewriting CC register

Kenneth — Mon, 24 Nov 2025 20:58:13 GMT

It's been a while since I looked at nRF5 SDK, can you fix these for me?

Kenneth

RE: Timer compare not matching after rewriting CC register

janvb — Mon, 24 Nov 2025 11:04:32 GMT

devzone.nordicsemi.com/.../V2.0testnordic.zip

RE: Timer compare not matching after rewriting CC register

Kenneth — Mon, 24 Nov 2025 09:51:09 GMT

Hi,

If you don't want to share it in this public case (drag and drop a zip file here), then I guess you need to make a new private case.

Kenneth

RE: Timer compare not matching after rewriting CC register

janvb — Fri, 21 Nov 2025 15:26:51 GMT

OK, I have prepared a simplified project for you.

Please let me know hoe I can share this.

RE: Timer compare not matching after rewriting CC register

Kenneth — Tue, 18 Nov 2025 21:14:30 GMT

If you want us to take a look at this, I need a full simplified project that recreate the issue in specific that can be run on a DK.

Kenneth

RE: Timer compare not matching after rewriting CC register

janvb — Tue, 18 Nov 2025 10:10:45 GMT

Hello Kenneth.

I am using nRF_SDK_17.1.0

This is the ppi config:

static void ppi_init(void) //MOSFET switching and mainteance
{

uint32_t input_evt_addr;
uint32_t gpiote_task_addr_set;
uint32_t gpiote_task_addr_clr;
uint32_t timer_task_clr;
uint32_t timer_task_cap;
uint32_t timer_evt_addr1;
uint32_t timer_evt_addr2;
uint32_t vmon1_evt_addr;
uint32_t vmon2_evt_addr;

uint32_t tdia_task_cap0;
uint32_t tdia_task_cap1;
uint32_t tdia_task_clr;

// Configure GPIOTE IN event
nrf_drv_ppi_init();
nrf_drv_ppi_channel_alloc(&ppi_channel1);
nrf_drv_ppi_channel_alloc(&ppi_channel2);
nrf_drv_ppi_channel_alloc(&ppi_channel3);
nrf_drv_ppi_channel_alloc(&ppi_channel4);
nrf_drv_ppi_channel_alloc(&ppi_channel5);

nrfx_gpiote_in_config_t input_config =
{
.is_watcher = false,
.hi_accuracy = true,
.pull = NRF_GPIO_PIN_NOPULL,
.sense = NRF_GPIOTE_POLARITY_TOGGLE,
.skip_gpio_setup = false
};
nrfx_gpiote_in_init(Pin_ZC, &input_config, gpiote_event_handler);
nrfx_gpiote_in_event_enable(Pin_ZC, true); //zero cross

nrfx_gpiote_out_config_t out_config = NRFX_GPIOTE_CONFIG_OUT_TASK_HIGH;
nrfx_gpiote_out_init(Pin_DON, &out_config); //MOSFET on

input_evt_addr = nrfx_gpiote_in_event_addr_get(Pin_ZC);
gpiote_task_addr_set = nrfx_gpiote_set_task_addr_get(Pin_DON);
gpiote_task_addr_clr = nrfx_gpiote_clr_task_addr_get(Pin_DON);
timer_evt_addr1 = nrfx_timer_event_address_get(&m_timer3,NRF_TIMER_EVENT_COMPARE1);
timer_evt_addr2 = nrfx_timer_event_address_get(&m_timer3,NRF_TIMER_EVENT_COMPARE2);
timer_task_clr = nrfx_timer_task_address_get(&m_timer3, NRF_TIMER_TASK_CLEAR);
timer_task_cap = nrfx_timer_task_address_get(&m_timer3, NRF_TIMER_TASK_CAPTURE0);

nrfx_ppi_channel_assign(ppi_channel1,input_evt_addr, timer_task_cap);
nrfx_ppi_channel_fork_assign(ppi_channel1, timer_task_clr);
nrfx_ppi_channel_assign(ppi_channel2, timer_evt_addr1, gpiote_task_addr_clr);
nrfx_ppi_channel_assign(ppi_channel3, timer_evt_addr2, gpiote_task_addr_set);

nrfx_ppi_channel_enable(ppi_channel1); // capture and clear timer on zero cross
nrfx_ppi_channel_enable(ppi_channel2); //MOSFET on (CC1)
nrfx_ppi_channel_enable(ppi_channel3); //MOSFET off (CC2)

nrfx_gpiote_out_task_enable(Pin_DON);

RE: Timer compare not matching after rewriting CC register

Kenneth — Tue, 18 Nov 2025 09:42:49 GMT

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

RE: Timer compare not matching after rewriting CC register

janvb — Mon, 17 Nov 2025 13:16:29 GMT

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.

RE: Timer compare not matching after rewriting CC register

Kenneth — Mon, 17 Nov 2025 12:38:35 GMT

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

RE: Timer compare not matching after rewriting CC register

janvb — Mon, 17 Nov 2025 12:32:27 GMT

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.

RE: Timer compare not matching after rewriting CC register

Kenneth — Sun, 16 Nov 2025 18:09:34 GMT

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

RE: Timer compare not matching after rewriting CC register

janvb — Fri, 14 Nov 2025 14:30:08 GMT

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).

RE: Timer compare not matching after rewriting CC register

Kenneth — Wed, 29 Jan 2025 08:49:02 GMT

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

RE: Timer compare not matching after rewriting CC register

Michael — Wed, 29 Jan 2025 06:32:51 GMT

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.

RE: Timer compare not matching after rewriting CC register

Kenneth — Tue, 28 Jan 2025 22:41:41 GMT

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