DPPI NRFX Support NRF54L15

[LukeC]

DPPI is not able to build with SDK 2.8.

The issue seems to be the NRF54L15 has 4 DPPI peripherals, yet the NRFX hal version 2.8 only works with one.

// Driver for single instance DPPI
#if NRFX_CHECK(NRFX_DPPI_ENABLED) && (!defined(DPPIC_COUNT) || (DPPIC_COUNT == 1))

Would it be recommended to clone the latest release of the NRFX hal to get support for the 54L15?

github.com/.../nrfx_dppi.c

[Hung Bui]

Hi Luke, 
If you take a look at \zephyr\modules\hal_nordic\nrfx\CMakeLists.txt  you can find this:

So nrfx_gppi_dppi_ppib_lumos.c is used, not nrfx_dppi.c. 

[LukeC]

Hmm, so it looks like I should be using the "gppi" library -  #include <helpers/nrfx_gppi.h> then correct?  

I am trying to create multiple low-power PWM on the 54L15 with the GRTC and the GPIOTE.  I could do this on the 52 series, however this had a dedicated RTC that I could use for PWM.  With the 54L, it looks like there is just one global RTC with multiple CC channels.  is it still possible set up multiple low power PWMs using the GRTC and GPIOTE with the PPI events/tasks?   

[LukeC]

Hung,

Thanks again for all of your time and effort on this.

1. NR52 Method

Dedicated RTC2 (RTC0 is BLE, RTC1 is app timer)

RTC2 - 2 CC channels used

RTC Channel0 - PWM Duty Factor 

RTC Channle1 - PWM base timer/reload

PPI - 3 channels

PPI Chan0 - RTC Channel0 Compare Event -> GPIOTE task set

PPI Chan1 - RTC Channel1 Compare Event -> GPIOTE task clr

PPI Chan2 - RTC Channel1 Compare Event -> RTC Task Clear

Functionality

PPI Chan0 sets the LED for the PWM.

PPI Chan1 clears the LED PWM for the base timer/reload

PPI Chan2 Clears the RTC count to restart the PWM/CC Channels

2. Issues implementing this in NRF54L15

There is one GRTC not multiple RTCs like in the NRF52. Therefore one cannot dedicate an RTC to this.  If the RTC Clear Task is called, this will reset the RTOS base timer correct?  And reset the logging timestamp?

I don't see another way to restart the CC channels on the GRTC in the NRF54L.  I can copy the above configuration in the NRF54 exactly, except PPI Chan2.

I am also not sure even if I use the NRF_GRTC_TASK_CLEAR task, if the GRTC CC channels will re-enable since they are one-shot in the GRTC.

[LukeC]

uint8_t ppi_ccchan0, ppi_chan1, ppi_chan2, ppi_chan2, ppi_chan3;

void ppi_init(void)
{
    nrfx_err_t nrfx_err;
    uint32_t event_address, task_address;

    // Set PWM PIN on RTC compare channel0 / Duty factor channel
    nrfx_err = nrfx_gppi_channel_alloc(&ppi_ccchan0);

    if (nrfx_err != NRFX_SUCCESS)
    {
        LOG_ERR("nrfx_gppi_channel_alloc failed.");
    }

    event_address = nrfx_grtc_event_compare_address_get(ccchan0.channel);
    task_address = nrfx_gpiote_set_task_address_get(&gpiote_inst, GPIOTE_PIN);
    nrfx_gppi_channel_endpoints_setup(ppi_ccchan0, event_address, task_address);
    nrfx_gppi_channels_enable(BIT(ppi_ccchan0));

    // Clear PWM PIN on RTC compare channel1 / pwm base timer
    nrfx_err = nrfx_gppi_channel_alloc(&ppi_chan1);

    if (nrfx_err != NRFX_SUCCESS)
    {
        LOG_ERR("nrfx_gppi_channel_alloc failed.");
    }

    event_address = nrfx_grtc_event_compare_address_get(ccchan1.channel);
    task_address = nrfx_gpiote_clr_task_address_get(&gpiote_inst, GPIOTE_PIN);
    nrfx_gppi_channel_endpoints_setup(ppi_chan1, event_address, task_address);

    nrfx_gppi_fork_endpoint_setup(ppi_chan1,
                                  nrfx_grtc_task_address_get(NRF_GRTC_TASK_CLEAR));

    nrfx_gppi_channels_enable(BIT(ppi_chan1));
}

here is an attempt to use the GRTC_TASK_CLEAR.  This still only sets the led once/clears the led once.

[Hung Bui]

Thanks Luke. I think it's more clear for me now. 
I am now checking internally to see if there is any option. 

[Jeremy]

Were you ever able to find a solution to this?

I couldn't find an answer so created a new post ( nRF54L15 GRTC -> GPPI -> GPIOTE pipeline ), but if you catch this notification and have some insight I'd appreciate it.

[Hung Bui]

Hi Jeremy, 
Unfortunately there is no update for a solution for this yet. I have escalated the issue again internally.