2 x NRF_PPI with FORK does not have the same behavior as 4 x NRF_PPI

RE: 2 x NRF_PPI with FORK does not have the same behavior as 4 x NRF_PPI

Edvin — Tue, 18 Jul 2023 14:20:20 GMT

I see (I believe).

I also believe it is correct that you may experience a 0 in one of the CC[n], if you capture at the same event that you are resetting.

I am not sure exactly how you are loading the new values, but perhaps it is not important.

Since you are manually resetting the timer using PPI/fork, can you try to remove the clear short? And if that doesn't work, remove the clear ppi task, so that you only use one at the time?

Other than that, I can't say that I am a fan of clearing the timer at the same time that you are capturing it. Is there some way you can avoid it?

I have no idea of what frequencies you are using (if this triggers once per second, or 1000 times per second). Is there a chance to involve the CPU? If so, you wouldn't need to reset the timer at all, but you could just add the old CC value to the new one?

BR,

Edvin

RE: 2 x NRF_PPI with FORK does not have the same behavior as 4 x NRF_PPI

Marne — Tue, 18 Jul 2023 13:39:45 GMT

What I am trying to do is to set a value of my timer in sync with the timer and an external event.

The external event is triggering the timer periodically. The timer will run until CC[2], modifying GPIOTEs at CC[0] and CC[1]. Due to the real time requirements of this system I cannot "randomly" change any of CC[0-2]. Instead I use CC[3] to transfer the values at the right time.

In order to do this I load the new value for (for instance) CC[0] in CC[3] and use a PPI to link EVENT_COMPARE[3] -> TASKS_CAPTURE[0]. This allows me to only update my CCs at a very controlled time, without using the CPU directly.

In the case that is failing I am reducing the value of CC[2], the maximum value of the timer. So CC[3] < CC[2]. The timer triggers at CC[3] first, which loads the new value to CC[2] and resets the timer for the next period. I havent been able to determine if it is during this period, or the next that it fails.

From what I can see with my oscilloscope the GPIOTE task which is supposed to Toggle the pin fails to execute. This task is triggered at both CC[0] and CC[1], both of which are separated by at least 2 timer ticks, and less than CC[2] by at least 2.

It looks like everything recovers for the susequent period, I get one incorrect period. I believe this would not happen if I loaded a 0 to CC[2].

RE: 2 x NRF_PPI with FORK does not have the same behavior as 4 x NRF_PPI

Edvin — Tue, 18 Jul 2023 13:22:37 GMT

Hello,

Can you describe in a bit more detail in what way it doesn't work? Do you see a lot of 0x00000000 in your capture registers?

When doing capture and clear basically at the same time, it is a bit random which one will execute first. Perhaps the two different chips behaved a bit differently doing this.

Do you strictly need to capture the timer when you know that it triggered from a compare?

Regardless, can you describe what the intended behavior is, and what you are actually seeing?

Best regards,

Edvin