nRF5340 clock sources

[Hiihtaja]

Hello !

It is not so clear default clock sources on nRF5340 app and net cores.

1.

As zephyr clock sources, SYSTICK timers are in use in both cores and timer clocking from external 32kHz XTAL oscillator.

Is this so ?

Should I specify  CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y in prj.conf this line and for what core ?

2. RTCx timers is not used by default.

if I need to use those ( RTC0 on app core, RTC1 on net core), I should specify CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y on both core's configuration ?

3. App core CPU clock is 128Mhz by default.

How to be sure if it clocked from XTAL oscillator ?

How to change clock to 64Mhz ?

4. Net core CPU clock is 64 Mhz by default.

How I be sure if it clocked from crystal oscillator ?

I can see clock_init() what use

clk_mgr = z_nrf_clock_control_get_onoff(CLOCK_CONTROL_NRF_SUBSYS_HF);

Should I use this code for app core as well or only on net core ?

On net core I use NRF_TIMER2 and RADIO and they need to be clocked form HF XTAL.

Regards,

Eugene

[Hiihtaja]

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

[ovrebekk]

Hi Eugene

Hiihtaja said:

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

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. 

Hiihtaja said:

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

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

Hiihtaja said:

What I should do with other case :

NRF_RADIO_EVENT_ADDRESS -> NRF_TIMER_TASK_CAPTURE1

NRF_RADIO_EVENT_ADDRESS -> NRF_CCM_TASK_CRYPT

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

[Hiihtaja]

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

[ovrebekk]

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

[Hiihtaja]

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