nRF5340 clock sources

RE: nRF5340 clock sources

ovrebekk — Fri, 05 May 2023 08:56:05 GMT

Glad I could help Eugene, the best of luck 🙂

RE: nRF5340 clock sources

Hiihtaja — Thu, 04 May 2023 12:35:37 GMT

Hi Torbjorn !

Thank you !

I think I get point of DPPI on nRF53 and can compose pairs what are need.

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Thu, 04 May 2023 12:18:49 GMT

Hi Eugene

TXREADY and READY should have exactly the same timing in TX mode. The TXREADY and RXREADY events are basically a replacement for the READY event, but the READY event was kept in the radio to avoid breaking the backwards compatibility.

The PHYEND event is mainly used in 802.15.4 mode, and I don't know how much delay there would be in other modes, but I would expect it to happen very quickly after the END event.

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Wed, 03 May 2023 09:38:33 GMT

Hi Torbjorn !

I think for avoid collisions , have sense to use different radio events for profile radio and dedicated dppi channels

e,g RX/TX ready and PHYEND.

if shorts:

nrf_radio_shorts_set(NRF_RADIO,

(NRF_RADIO_SHORT_READY_START_MASK | NRF_RADIO_SHORT_END_DISABLE_MASK | NRF_RADIO_SHORT_ADDRESS_RSSISTART_MASK));

For example in case of TX path

nrfx_gppi_channel_endpoints_setup(ppi_radio_event_rxtxready,

nrf_radio_event_address_get(NRF_RADIO, NRF_RADIO_EVENT_TXREADY), nrfx_gpiote_set_task_addr_get(DBG_PIN5));

nrfx_gppi_channel_endpoints_setup(ppi_radio_event_phyend,

nrf_radio_event_address_get(NRF_RADIO, NRF_RADIO_EVENT_PHYEND),

nrfx_gpiote_clr_task_addr_get(DBG_PIN5));

I think TXREADY nad PHYEND have almost exact timimg as READY and END events.

Do you see any problem with this scheme ?

No idea yet if exist some anomalies what generate false events sometimes.

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Wed, 03 May 2023 07:43:09 GMT

Hi Eugene

Yes, in the nRF52 series and later there are dedicated SET and CLR tasks for a GPIOTE OUT channel, allowing you to easily connect different events that will either clear or set the output pin.

The OUT event is really only useful if you want to be able to toggle a pin, rather than set or clear it.

Your code should be updated with another ppi channel that you can use to clear the pin when the END event occurs in the radio.

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Tue, 02 May 2023 11:56:06 GMT

Hi Torbjorn !

It dosn't work for me.

But looks like SET and CLR tasks are created automatically and I can use OUT or SET with READY_EVENT and CLR with END event.

Can it be counted as right solution as well OR better try to use OUT task twice ?

and nrfx_gppi_task_endpoint_setup(..) ?

I use like this now.

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_READY, ppi_radio_event_ready);

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, ppi_radio_event_ready);

uint32_t channels_mask = BIT(ppi_radio_event_ready);

and attach different GPIO lines ( RX and TX activity ) after that as usually :

if (is_tx) {

nrfx_gppi_fork_endpoint_clear(ppi_radio_event_ready, nrfx_gpiote_set_task_addr_get(DBG_PIN6));

nrfx_gppi_fork_endpoint_setup(ppi_radio_event_ready, nrfx_gpiote_set_task_addr_get(DBG_PIN5));

nrfx_gpiote_out_task_enable(DBG_PIN5);

} else {

nrfx_gppi_fork_endpoint_clear(ppi_radio_event_ready, nrfx_gpiote_set_task_addr_get(DBG_PIN5));

nrfx_gppi_fork_endpoint_setup(ppi_radio_event_ready, nrfx_gpiote_set_task_addr_get(DBG_PIN6));

nrfx_gpiote_out_task_enable(DBG_PIN6);

}

I will also try to use RXREADY and TXREADY events instead of READY,( I have radio shortcut READY)

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Fri, 28 Apr 2023 09:04:03 GMT

Hi Eugene

It should be possible to associate two different events with the same GPIOTE OUT task, yes.

Are you not able to get it to work?

If so, could you try using the nrfx_gppi_task_endpoint_setup(..) function instead and see if it works better?

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Thu, 27 Apr 2023 12:48:37 GMT

Hi Torbjorn !

Does gpiote task is also can't be added in 2 places ?

I create GPIOTE task for toggle GPIO pin and would like to measure TX frame duration between READY and END events.

nrfx_gppi_fork_endpoint_setup(ppi_radio_event_ready, nrfx_gpiote_out_task_addr_get(DBG_PIN5));

nrfx_gppi_fork_endpoint_setup(ppi_radio_event_end, nrfx_gpiote_out_task_addr_get(DBG_PIN5));

nrfx_gpiote_out_task_enable(DBG_PIN5);

Should it work or not ?

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Wed, 26 Apr 2023 12:09:18 GMT

Hi Eugene

Sounds good. If you have any more questions or comments just let me know.

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Wed, 26 Apr 2023 08:45:28 GMT

Hi Torbjorn !

I also can see that one event can be distributed to multiple tasks easily by using one channel.

I will try to add to the same channel GPIOTE task for toggle external GPIO line.

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Wed, 26 Apr 2023 08:00:24 GMT

Hi Eugene

If you want to have all three tasks connected to the ADDRESS event all the time then there is no need to use the EGU.

But if you need to change dynamically which tasks get activated on the ADDRESS event and which does not, then you will need to use the EGU, since the DPPI does not allow an event to publish to two different DPPI channels at the same time.

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Tue, 25 Apr 2023 09:16:50 GMT

Hi Torbjorn !

In DS written

"One event can trigger multiple tasks by subscribing different tasks to the same channel."

It means I should be able to map address event to 3 tasks at list

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_ADDRESS, ppi_radio_events_address);

nrf_timer_subscribe_set(NRF_TIMER2, NRF_TIMER_TASK_CAPTURE4, ppi_radio_events_address);

nrf_ccm_subscribe_set(NRF_CCM, NRF_CCM_TASK_CRYPT, ppi_radio_events_address);

For what reason I need EGU in this case ?

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Mon, 17 Apr 2023 07:32:26 GMT

Hi Eugene

[quote user="Hiihtaja"]This is explain behaviour what I have. Does it really written in DS or other document somewhere ?[/quote]

The difference between PPI and DPPI is not really documented. You would need to read the PPI and DPPI chapters in the respective product specifications and understand that there is an architectural difference between the two, even though they essentially do the same thing.

[quote user="Hiihtaja"]Could you point me to sample where 3 events are attached to one channel /single task ?[/quote]

All you have to do is have 3 events publish to the same DPPI channel.

[quote user="Hiihtaja"]

What I should do with other case :

NRF_RADIO_EVENT_ADDRESS -> NRF_TIMER_TASK_CAPTURE1

NRF_RADIO_EVENT_ADDRESS -> NRF_CCM_TASK_CRYPT

[/quote]

i think your EGU proxy idea will work, yes.

Essentially you have to use one DPPI channel to connect RADIO_EVENT_ADDRESS to two distinct EGU TASKS, for instance EGU_TASK_TRIGGER[0] and EGU_TASK_TRIGGER[1].

At this point you have basically converted the single ADDRESS event into two events (EGU_EVENT_TRIGGERED 0 and 1) which will both happen when the ADDRESS event occurs.

Then you can use two more DPPI channels to connect EGU_EVENT_TRIGGERED[0] to TIMER_TASK_CAPTURE1, and EGU_EVENT_TRIGGERED[1] to CCM_TASK_CRYPT.

These last two DPPI channels can then be assigned to groups, allowing you to enable and disable them easily.

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Sat, 15 Apr 2023 06:40:53 GMT

Hi Torbjorn !

Thank you !

This is explain behaviour what I have. Does it really written in DS or other document somewhere ?

I will try to use different timers channel but I should rearrange code a bit.

Could you point me to sample where 3 events are attached to one channel /single task ?

What I should do with other case :

NRF_RADIO_EVENT_ADDRESS -> NRF_TIMER_TASK_CAPTURE1

NRF_RADIO_EVENT_ADDRESS -> NRF_CCM_TASK_CRYPT

It looks as simple fork but again the same event should force 2 tasks and ADDRESS can be part of group

where 3 events force one task.

How you handle those cases in your SoftDevices.

Can EGU peripheral be used as proxy in those cases and simplify these ?

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Fri, 14 Apr 2023 14:14:02 GMT

Hi Eugene

Thanks for the detailed description, now I understand the issue more clearly.

What you say is correct. The DPPI implementation in the nRF53 has a limitation that the PPI controller in the nRF52 doesn't have, and this is the fact that a task can only publish to one DPPI channel at a time, and an event can only subscribe to one DPPI channel at a time.

So while a single channel can have an unlimited number of subscriptions or publishers, a single subscriber or publisher can only connect to a single DPPI channel.

This does mean that there are certain PPI configurations that can not be properly duplicated using the DPPI controller.

In order to connect the READY, ADDRESS and END events of the radio to the CAPTURE1 task you need to use a single DPPI channel for this, which means you can't easily disable one or the other connections.

Do you have 2 free CC registers in the timer?
If so, would it be an alternative to use separate CC registers for READY, ADDRESS and END?

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Thu, 13 Apr 2023 05:24:27 GMT

Hi Torbjørn !

Yes and no.

for initiate RX/TX I have

if (is_tx) {

NRF_TIMER_EVENT_COMPARE2 -> NRF_RADIO, NRF_RADIO_TASK_TXEN

} else {

NRF_TIMER_EVENT_COMPARE2 -> NRF_RADIO_TASK_RXEN

}

and it work as expected

After that

I have 3( or 4) dedicated channels and connect 3 different events to one task

NRF_RADIO_EVENT_READY -> NRF_TIMER_TASK_CAPTURE1

NRF_RADIO_EVENT_ADDRESS -> NRF_TIMER_TASK_CAPTURE1

NRF_RADIO_EVENT_END -> NRF_TIMER_TASK_CAPTURE1

and coming soon

NRF_RADIO_EVENT_ADDRESS -> NRF_CCM_TASK_CRYPT

And this set of channels on nRF52 to be enabled before TX/RX start, work fine for nRF52

But not on nRF53

I have got conclusion that different events can't be linked to the same task ( capture1) like on nRF52.

Only one channel conduct event.

Can it be explained ? Why I can't configure and enable all 3 channels what should pass 3 different events to one task ?

If we drop forks and groups and able to reserve dedicated channel for each required pair, what kins od limitation we might have ?

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Wed, 12 Apr 2023 14:14:33 GMT

Hi Eugene

I expect the difference here is down to the difference between the PPI controller in the nRF52 series and the DPPI controller in the nRF53 series.

With the nRF52/PPI a single PPI channel can at most connect one event to two tasks (using the FORK endpoint for the second task).

With the nRF53/DPPI a single DPPI channel can connect a single event to as many tasks as you want, since there is no limit on how many tasks can subscribe to the same DPPI channel.

In order to connect one event to three tasks with the nRF52/PPI you need to use two distinct PPI channels, whereas on the nRF53 you can get away with one.

Does this explain the inconsistencies you are experiencing?

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Tue, 11 Apr 2023 12:24:39 GMT

Hi Torbjørn !

Yes I allocate channels numbers once and after that enable/disable/refresh public and subscribe pairs ( I write exactly the same values for refresh channel).

In my case I would like to configure 3 channels for catch 3 radio events.

READY, ADDRESS and END. After that I enable RX/TX(+shortcuts.)

BUT

I can't configure channels beforehand IF all 3 channels expected to have end task as the same Timer capture

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, channel1);

so even own channels are allocated and events is not happens at the same time, they can't execute capture task.

And this is make difference with nRF52 MCU ( 3 pairs configured and enabled before TX/RX start).

For overcome this limitation I configure (refresh values ) next pair in RADIO ISR when receive previous event.

And it works as expected.

Looks like channel, where pairs written the last a able to capture timer.

And it not loosk as fork case e,g one to many. It is like many to one ?

Can it be explained some how ?

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Tue, 11 Apr 2023 12:04:44 GMT

Hi Eugene

I am not quite sure I understand your problem, but can you confirm that you are constantly freeing and re-allocating channels?

This is not really how the DPPI is meant to be used. If you have a DPPI channel that you will use repeatedly for the same purpose you should not free it after you allocate it, if you do this then it makes sense that the driver might assign you a different channel ID and that all the existing configurations will stop working.

Instead you should simply disable the channel when you don't need it, and enable it afterwards.

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Tue, 04 Apr 2023 16:35:47 GMT

Hi Torbjørn !

I found difference.

It is not possible to specify beforehand pairs where the same subscribe is used ( even channel is different)

Internally it make last subscribe active only. Even channels are disabled and freed every TX loop.

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_READY, ppi_radio_events_ready);

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, ppi_radio_events_ready);

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_ADDRESS, ppi_radio_events_address);

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, ppi_radio_events_address);

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_END, ppi_radio_events_end);

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, ppi_radio_events_end);

I need to to do sequentially if would like to collect all events

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_READY, ppi_radio_events_ready);

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, ppi_radio_events_ready);

enable

Get interrupt for READY

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_ADDRESS, ppi_radio_events_address);

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, ppi_radio_events_address);

enable

Get interrupt for ADDRESS

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_END, ppi_radio_events_end);

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, ppi_radio_events_end);

enable

Get interrupt for END

In this way it works.

Have it sense for DPPI ?

Regards,

Eugene

RE: nRF5340 clock sources

Hiihtaja — Fri, 31 Mar 2023 13:01:28 GMT

Hi Torbjørn !

Yes TX and RX is not enabled at the same time.

I can see difference between nRF52 and nRF53 only in case that DPPI channel need to be allocated from pool once and used after that.

Channels should be usable all the time.

TX/RX need to be enabled/disabled only when mode change from TX to RX and vise versa.

Channels publish and subscribe can be reconfigured with the same values multiple times.

If channel enabled, it should conduct event from source to target . ( Timer's event ISR can be enabled or not )

All DPPI operations can be done in ISR context.

If radio disabled for a while, no need to refresh public/subscribe pairs.

When radio disabled, all DPPI channels are also disabled.

But something else exist what do DPPI not working as expected.

I need to write more simple radio for be sure if all pairs works as expected.

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Thu, 30 Mar 2023 11:56:47 GMT

Hi Eugene

Once configured a PPI or DPPI channel will just operate in the background without needing any upkeep, refresh etc.

Even if the event register is not cleared, or you don't have interrupts enabled for certain events, they will still be available through the DPPI and trigger tasks whenever they occur.

If the channels don't appear to work it's typically caused by a configuration issue, by forgetting to enable the channels, or that the receiving peripheral gets the task at the wrong time (when it is not in a state to process that task for instance).

Is it intentional that you have two different events connected to the same capture register (CAPTURE1), and that you use the same compare register to trigger both TXEN and RXEN (COMPARE2) ?

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Wed, 29 Mar 2023 11:14:07 GMT

Hi Torbjørn !

Yes,

I allocate and specify publish/subscribe pairs.

After that after each disable period

nrf_radio_task_trigger(NRF_RADIO, NRF_RADIO_TASK_DISABLE);

I have enabled required channels, enable RX or TX task.

and disable all channels after RX/TX transaction or timeout.

So I can just enable/disable channels and clearing source of event if need.

No need to refresh publish/subscribe pairs and clean/enable something else ?

Looks like in my scheme only timer can cause problems if event is not generated.

Regards,

Eugene

RE: nRF5340 clock sources

ovrebekk — Wed, 29 Mar 2023 10:19:39 GMT

Hi Eugene

Do you remember to allocate and enable the DPPI channels that you are using?

You should allocate them first (like shown here), then configure the publish and subscribe registers, before ensuring to enable the channels you need (like shown here).

Best regards
Torbjørn

RE: nRF5340 clock sources

Hiihtaja — Tue, 28 Mar 2023 16:15:55 GMT

Hi Torbjørn !

Yes . I have problem with DPPI.

in nRF52 I have used

TIMERX is TIMER2

/* Ready Event */

NRF_PPI->CH[RADIO_READY_CH].EEP = (uint32_t)&NRF_RADIO->EVENTS_READY;

NRF_PPI->CH[RADIO_READY_CH].TEP = (uint32_t)&NRF_TIMERX->TASKS_CAPTURE[TIMESTAMP_REG];

/* Address Event */

NRF_PPI->CH[RADIO_ADDRESS_CH].EEP = (uint32_t)&NRF_RADIO->EVENTS_ADDRESS;

NRF_PPI->CH[RADIO_ADDRESS_CH].TEP = (uint32_t)&NRF_TIMERX->TASKS_CAPTURE[TIMESTAMP_REG];

NRF_PPI->CHENSET = (1UL << RADIO_READY_CH) | (1UL << RADIO_ADDRESS_CH) | (1UL << RADIO_END_CH);

/* Configure PPI for RADIO TX/RX */

NRF_PPI->CH[RADIO_TXEN_CH].EEP = (uint32_t)&NRF_TIMERX->EVENTS_COMPARE[SCHEDULE_REG];

NRF_PPI->CH[RADIO_TXEN_CH].TEP = (uint32_t)&NRF_RADIO->TASKS_TXEN;

NRF_PPI->CH[RADIO_RXEN_CH].EEP = (uint32_t)&NRF_TIMERX->EVENTS_COMPARE[SCHEDULE_REG];

NRF_PPI->CH[RADIO_RXEN_CH].TEP = (uint32_t)&NRF_RADIO->TASKS_RXEN;

And RX/TX I have enabled when need.

in nRF53 I have created channels and configure those and enable when need.

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_READY, ppi_radio_events_ready);

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, ppi_radio_events_ready);

nrf_radio_publish_set(NRF_RADIO, NRF_RADIO_EVENT_ADDRESS, ppi_radio_events_address);

nrf_timer_subscribe_set(NRF_TIMERX, NRF_TIMER_TASK_CAPTURE1, ppi_radio_events_address);

nrf_timer_publish_set(NRF_TIMERX, NRF_TIMER_EVENT_COMPARE2, ppi_radio_tx_enable);

nrf_radio_subscribe_set(NRF_RADIO, NRF_RADIO_TASK_TXEN, ppi_radio_tx_enable);

nrf_timer_publish_set(NRF_TIMERX, NRF_TIMER_EVENT_COMPARE2, ppi_radio_rx_enable);

nrf_radio_subscribe_set(NRF_RADIO, NRF_RADIO_TASK_RXEN, ppi_radio_rx_enable);

And events are not generated. I can see code samples when EGU in use also.

But can I be sure if my DPPI channels configured properly and I just enable/disable those when need ?

Or those pairs need some EGU proxy or the need to be cleaned after each event or something else.

I think channel can pass any amount of events and I just need to clean target in time for avoid lost of next one.

Regards,

Eugene