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

[Jared]

Hi,

It's best to specify for each core what clock source they should run at. 

The RTC is not a viable clock source for the Low Frequency Controller. 

The documentation states:

Each core has a number of low frequency clock (LFCLK) control instances. Each instance distributes one or more clocks to the core.

The LFCLK control instance in each core distributes the 32.768 kHz PCLK32KI peripheral clock to its corresponding core. The LFCLK clock is sourced from the power and clock subsystem to each LFCLK control instance.

In order to generate the LFCLK clock, the LFCLK controller uses the following LFCLK sources:
32.768 kHz RC oscillator (LFRC)
32.768 kHz crystal oscillator (LFXO)
32.768 kHz synthesized from HFCLK (LFSYNT)

The RTC will run off the LFCLK.

When started, the RTC will automatically request the LFCLK source with RC oscillator if the LFCLK is not already running.

You can check what clock source the LFCLK is running at by checking the LFCLKSTAT register.

regards

Jared 

[Hiihtaja]

Hi Jared !

But what about HFLK XTAL. Should I do some enabling of it ?

Some radio samples requiest it by _nrf_clock_control_get_onoff(CLOCK_CONTROL_NRF_SUBSYS_HF);

other not.

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

[ovrebekk]

Hi Eugene

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

Best regards
Torbjørn

[Hiihtaja]

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

[ovrebekk]

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

[Hiihtaja]

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

[ovrebekk]

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

[Hiihtaja]

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

[ovrebekk]

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

[Hiihtaja]

Hi Torbjorn !

Thank you !

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

Regards,

Eugene