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

[ovrebekk]

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

[Hiihtaja]

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

[ovrebekk]

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

[Hiihtaja]

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

[ovrebekk]

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