nRF53 DPPI and low-power/low-latency

[Stephan Walter]

I am using the DPPI feature in the nRF5340 to trigger an SPI transaction from a GPIO edge with a delay.

In more detail:

GPIOTE IN event triggers RTC clear task

RTC compare event triggers SPIM start task

This works fine so far, now I am looking into reducing power consumption.

The low-power mode of GPIOTE seemed like what I should use. However when I enable it by setting GPIOTE.LATENCY=LowPower, the SPIM transaction is no longer triggered correctly. MOSI goes low but nothing happens on the chip select and clock pins.

My suspicion is that using low-power mode disables the HF clock, which is not re-enabled correctly when SPIM needs it.

When I leave GPIOTE low power mode enabled but set the constant latency sub-mode (CONSTLAT task), the SPIM transaction works fine.

I have several questions:

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

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

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?

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?

[Kazi Afroza Sultana]

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

 

[Stephan Walter]

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

[Kazi Afroza Sultana]

Thank you Stephan. I am glad to hear that. 

BR

Kazi Afroza Sultana