nRF53 DPPI and low-power/low-latency

RE: nRF53 DPPI and low-power/low-latency

Kazi Afroza Sultana — Tue, 18 Jan 2022 08:14:31 GMT

Thank you Stephan. I am glad to hear that.

Kazi Afroza Sultana

RE: nRF53 DPPI and low-power/low-latency

Stephan Walter — Mon, 17 Jan 2022 07:38:19 GMT

Hi Kazi,

Thank you for the quick response.

I think I got confused by the behaviour of the nRF53, as that is influenced by whether the debugger is connected or other HFCLK peripherals are active.

The problem with the SPIM not being triggered seems to be erratum 135. The workaround does fix the problem.

As to my question 4:

The same section in the specification also says that the SENSE fields must be set correctly, but it seems not to be necessary.

Please ignore this, I have now seen the case where there is no event triggered when the SENSE field is wrong.

So I will now do the following:

use GPIOTE.LATENCY=LowPower
use default low-power submode
always set SENSE field correctly for GPIOTE edge events
implement workaround for SPIM4 erratum 135

I appreciate your other explanations.

Best regards,

--Stephan Walter

RE: nRF53 DPPI and low-power/low-latency

Kazi Afroza Sultana — Fri, 14 Jan 2022 14:48:40 GMT

Hello Stephan,

Here are the answers to your questions:

1. Is it expected behavior that an LFCLK peripheral can't trigger an HFCLK peripheral, such as in my case?

No. The peripheral does not know where the PPI signals originate from. The HF clock is controlled automatically. So, it's not a problem when HFCLK is not running, SPIM should request this (HFCLK) automatically whenever needed.

As you said Real-time clock runs from the LF clock and this again triggers the HF clock peripheral when needed. This is how every application should work. The Low-frequency clock and its correspondence peripheral (RTC) consume 1uA range current. So, it works by default when the chip is in idle mode and controls the timing of the application. And as I said before HF clock peripherals start working based on need as they consume current in the 1mA range.

2. What is the relationship or difference between CONSTLAT sub-mode and GPIOTE.LATENCY=LowPower?

I don't think there is any relationship. Constant latency will keep HFCLK/HFINT running to guarantee short/consistent wakeup time for the System from Sleep mode to ON.

GPIOTE LowPower is related to how often the peripheral will check the state of the pin, so you will need to have a longer hold time for the signal to be detected. Power consumption is low.

I have asked our team to know How the internal works to detect the signal. I will let you know when will get the answer.

3. The specification states in section 7.14.4: "CONFIG.POLARITY=Toggle is not supported for LATENCY=LowPower." Does this apply to both event and task modes or only to event mode?

Only in Event mode.

4. The same section in the specification also says that the SENSE fields must be set correctly, but it seems not to be necessary. The reason for asking this is that the Zephyr GPIO implementation alters this field in several places, and I found it error-prone to always have to set it after e.g. calling gpio_pin_interrupt_configure. What exactly happens if the SENSE field is not as expected when GPIOTE is in low-power mode?

This question may not relevant to other problems. However, you can follow the Zephyr implementation of the GPIO interrupts, and use CONFIG_GPIO_NRF_INT_EDGE_USING_SENSE=y for low power operation.

I hope it helps.

Feel free to ask if you would like to know more.

Best Regards,

Kazi Afroza Sultana

RE: nRF53 DPPI and low-power/low-latency

Kazi Afroza Sultana — Fri, 14 Jan 2022 09:24:52 GMT

Hello Stephan,

I have been working on your questions. I will come to you with the answers shortly.

Best Regards,

Kazi Afroza Sultana