nRF52 wakeup time

RE: nRF52 wakeup time

Simonr — Fri, 15 Mar 2019 09:39:04 GMT

Yes, this should be possible. This ticket should be helpful I think.

Best regards,

Simon

RE: nRF52 wakeup time

tmav123 — Fri, 15 Mar 2019 08:08:08 GMT

One last question, in order to have the above wakeup time the vector table should be also placed in RAM.

This is easy when you have an non BLE application.

Is there a possibility to relocate the vector table in RAM with the Softdevice enabled?

Best Regards

Thanassis

RE: nRF52 wakeup time

Simonr — Thu, 14 Mar 2019 15:24:42 GMT

This seems correct! Sorry I didn't spot it. I don't see any reason to go through your project now, so if you are satisfied we can close this case.

Best regards,

Simon

RE: nRF52 wakeup time

tmav123 — Thu, 14 Mar 2019 13:11:31 GMT

Hi,

running the code from RAM seems to make the difference (GPIOTE irq executes after 3-4us of the external event).

What is the reason for this difference?

Best Regards

Thanassis

RE: nRF52 wakeup time

tmav123 — Thu, 14 Mar 2019 10:57:06 GMT

Hi,

please find attached the Keil project used for my tests.

Best Regards

Thanassis

devzone.nordicsemi.com/.../nRF52_5F00_wakeup_5F00_v1.00.zip

RE: nRF52 wakeup time

Simonr — Thu, 14 Mar 2019 09:37:58 GMT

I am guessing there is more to the wake up process that is causing the additional delay then. I can look at your project, and measure it here on our scope of course, but I can't guarantee that I will be able to decrease the delay any further.

Best regards,

Simon

RE: nRF52 wakeup time

tmav123 — Wed, 13 Mar 2019 17:54:41 GMT

Hi,

I have already changed to directly writing NRF_GPIO on the last test, but no significant change was observed (less than 1us).

The delay is from the nRF52832 wakeup time, and exist on both wakeups RTC and GPIOTE. When I disable the WFI command and the processor is not going for sleep, then the GPIOTE irq handler kicks after ~1us from the external event. So the GPIOTE irq & NRF_GPIO pin write is running very fast!

In the previous test, the PPI sets the GPIOTE pin automatically, but the GPIOTE task clear is done from the code inside of GPIOTE irq.

If you would like I can attach the Keil project used for this test.

Best Regards

Thanassis

RE: nRF52 wakeup time

Simonr — Wed, 13 Mar 2019 13:24:54 GMT

What about writing directly to NRF_GPIO, have you tried that yet to see if avoiding unnecessary headers reduces the delay. It seems here that the IRQ handler isn't able to set before the PPI event is completed, so I think this is as low of a delay you are going to get using PPI. Try and see if writing directly will cut the delay any more, and I will take a closer look if that doesn't work either.

Best regards,

Simon

RE: nRF52 wakeup time

tmav123 — Wed, 13 Mar 2019 10:34:03 GMT

Hi,

using the PPI & GPIOTE to set a pin output, shows that the nRF52 is setting the output 3us after the wakeup pulse.

The time for the GPIOTE irq handler to kick is ~12us.

The code used to set the pin output from the GPIOTE PORT event is:

    // ppi init - connect GPIOTE irq event to the GPIO_PPI_IRQ_PIN 
    nrf_ppi_channel_endpoint_setup(NRF_PPI_CHANNEL0, (uint32_t)&NRF_GPIOTE->EVENTS_PORT, (uint32_t)&NRF_GPIOTE->TASKS_SET[0]);
    nrf_ppi_channel_enable(NRF_PPI_CHANNEL0);
    
    // configure PPI GPIOTE pin
    nrf_gpiote_event_configure(0, GPIO_PPI_IRQ_PIN, NRF_GPIOTE_POLARITY_LOTOHI);
    nrf_gpiote_task_enable(0);

Best Regards

Thanassis

RE: nRF52 wakeup time

tmav123 — Tue, 12 Mar 2019 14:52:44 GMT

Hi,

the CPU that I use is the nRF52832_xxAA.

I will try to write direct to the NRF_GPIO to see if it has any measurable effect.

I think your suggestion to use the NRF_GPIOTE->EVENTS_PORT and feed it to the

PPI to toggle a GPIO pin, it will show the accurate wakeup timing.

I will let you know about the results.

Best Regards

Thanassis

RE: nRF52 wakeup time

Simonr — Tue, 12 Mar 2019 14:04:51 GMT

What is causing the extra time before the IRQ handler kicks in is likely that the GPIO driver causes some delay going through overheads. You can try writing to NRF_GPIO directly instead, to avoid any unnecessary calls. The nRF goes to sleep as soon as it is done, but you are measuring over a decoupling capacitor, which holds on to the voltage for some time, which is why you see the curve.

I suggest you take a look at the PPI, as I suspect it may suit your application, seeing as it doesn't depend on the CPU. I don't know which chip you are using so I attached the link to the nRF52840 PPI, if you want to use it please make sure to read the correct PS.

Best regards,

Simon

RE: nRF52 wakeup time

tmav123 — Tue, 12 Mar 2019 13:09:32 GMT

Hi Simon,

many thanks for your response.

I am using the internal 64Mhz as nRF52 clock.

As a LFCLK I am using an external 32.768Khz crystal which drives the RTC.

So I was expecting to see tSTART_HFINT: 3us for the HFINT startup + tIDLE2CPU: 3us for the

IDLE to CPU execute, but I see +10us till the irq handler is executed.

In the bellow example, you could see a clearer wakeup sequence from an external GPIO signal.

Is there anything else that I can do to reduce the extra 10us from my wake up time?

Another question is what is the reason that it takes so long for the nRF52 to go to sleep again after a WFI command.

The code used for the above example is the following:

#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include "nrf.h"
#include "nrf_gpio.h"

//==============================================================================


#define GPIO_WAKEUP_PIN             2
#define GPIO_IRQ_PIN                4
#define NRF_WAKEUP_SHOW_PIN         28 

//==============================================================================
//==============================================================================

void GPIOTE_IRQHandler(void)
{
    nrf_gpio_pin_set(GPIO_IRQ_PIN);
    
    if(NRF_GPIOTE->EVENTS_PORT)
    {
        if(NRF_P0->LATCH & ( 1 << GPIO_WAKEUP_PIN))
        {
            NRF_P0->LATCH = 1 << GPIO_WAKEUP_PIN;
        }
       
        NRF_GPIOTE->EVENTS_PORT = 0;
    }
    nrf_gpio_pin_clear(GPIO_IRQ_PIN);
}

//==============================================================================
int main(void)
{
//    interrupts_disable();
    
    // enable Instruction Cache
    NRF_NVMC->ICACHECNF |= NVMC_ICACHECNF_CACHEEN_Enabled << NVMC_ICACHECNF_CACHEEN_Pos;
    // enable Instruction Cache profiling
    // check NRF_NVMC->IHIT, NRF_NVMC->IMISS registers for i-cache analysis
    NRF_NVMC->ICACHECNF |= NVMC_ICACHECNF_CACHEPROFEN_Enabled << NVMC_ICACHECNF_CACHEPROFEN_Pos;

    //enable the DCDC converter
    NRF_POWER->DCDCEN = 1;
    //use the low power mode
    NRF_POWER->TASKS_LOWPWR = 1;


    // setup gpio sense pin
    NRF_GPIO->LATCH = (1<< GPIO_WAKEUP_PIN); //clear any latched DETECT
    NRF_GPIOTE->EVENTS_PORT = 0;
    nrf_gpio_cfg_sense_input(GPIO_WAKEUP_PIN, NRF_GPIO_PIN_NOPULL, NRF_GPIO_PIN_SENSE_LOW);
    NRF_GPIOTE->INTENSET = GPIOTE_INTENSET_PORT_Msk;
    NVIC_ClearPendingIRQ(GPIOTE_IRQn);
    NVIC_SetPriority(GPIOTE_IRQn, 6);  
    NVIC_EnableIRQ(GPIOTE_IRQn);
    
    nrf_gpio_cfg_output(GPIO_IRQ_PIN);
    nrf_gpio_cfg_output(NRF_WAKEUP_SHOW_PIN);
    nrf_gpio_cfg_output(RTC_IRQ_PIN);

    __enable_irq();
    
    while (true)
    {
        nrf_gpio_pin_clear(NRF_WAKEUP_SHOW_PIN);
        
        __WFI();
        
        nrf_gpio_pin_set(NRF_WAKEUP_SHOW_PIN);
        
    }
}
//==============================================================================

RE: nRF52 wakeup time

Simonr — Mon, 11 Mar 2019 08:51:02 GMT

Hi Thanassis

tSTART_HFINT startup time refers to the internal 64MHz oscillator, so when you are running on an external oscillator it nothing out of the normal that the startup time increases somewhat, actually I am surprised the startup delay isn't longer. To get closer to the what the PS states you can try to use the internal oscillator (HFINT).

Best regards,

Simon