nrf52 not entering sleep mode when accelerometer kx022 is used with twi manager

RE: nrf52 not entering sleep mode when accelerometer kx022 is used with twi manager

Bjørn Kvaale — Fri, 29 Mar 2019 11:14:38 GMT

I would use either RTC or the app_timer. It seems that you have already solved this, so I would just use what you have. I do not believe there are any advantages of using the first option I discussed in my last comment.

RE: nrf52 not entering sleep mode when accelerometer kx022 is used with twi manager

an-erd — Thu, 28 Mar 2019 17:30:49 GMT

Ok, but I didn't found on a packet timer concept in TWI transaction manager?

For my application with the sensors mentioned I need the delay between to packets send to the device. It's not just one time when initializing the sensor, but every cycle it's necessary. So it would be good to have something like a "delay package" for a specific device handover to the TWI transaction manager to wait for that specific TWI address.

In my current implementation I use RTC to do exactly this, but here I need to take care that the different device communications don't collide. So I need a combination of both, transaction manager and packet timer functionality.

Is there something like this available? If not, the ticket can be closed because the problem is solved.

RE: nrf52 not entering sleep mode when accelerometer kx022 is used with twi manager

Bjørn Kvaale — Thu, 28 Mar 2019 14:22:27 GMT

[quote user="an-erd"]But which is the best way to implement a delay using transaction manager transactions?[/quote]

You could consider setting in a delay in between sending packets with the packet timer. Otherwise, you could also use the RTC or app_timer to sleep while you are waiting for the KX022 accelerometer to initialize.

RE: nrf52 not entering sleep mode when accelerometer kx022 is used with twi manager

an-erd — Tue, 26 Mar 2019 15:55:37 GMT

Overall power consumption is not a problem, with the temperature/humidity sensor everything is fine, UART is no problem, I'm using RTT.

I rewrote the code part to use blocking TWI (without transaction manager) and also read the data sheet again. I found that the KX022 accel needs some delays (1.2/ODR) before putting in operation, and this seems to be the problem. With the blocking TWI and nfr_delay() the power consumption is ok, too.

The posted link 2 is a good reference, I didn't know, that I can schedule blocking transactions with the transaction manager, too.

But which is the best way to implement a delay using transaction manager transactions?

RE: nrf52 not entering sleep mode when accelerometer kx022 is used with twi manager

Bjørn Kvaale — Tue, 26 Mar 2019 14:19:14 GMT

It seems like the CPU is still running (check electrical specifications for the CPU from this link). Like you mentioned, for some reason it seems the TWI manager is keeping the CPU awake.

Could you try turning TWI off via the nrf_twi_mngr_uninit() function just to double check that it is the TWI manager that is leading to the interrupt from sleep issue?

This could also be related to the UART logging to the computer. Have you tested the sleep current by turning the UART off?

The documentation present here may also be helpful if you have not already seen it: link 1, link 2, link 3.

This case may also be helpful.

RE: nrf52 not entering sleep mode when accelerometer kx022 is used with twi manager

an-erd — Sun, 24 Mar 2019 19:05:18 GMT

I added two breakpoints in the function nrf_pwr_mgmt_run(), breakpoint A in the line with the first __WFE(), and the second breakpoint B when leaving the function again.

void nrf_pwr_mgmt_run(void)
{
    PWR_MGMT_FPU_SLEEP_PREPARE();
    PWR_MGMT_SLEEP_LOCK_ACQUIRE();
    PWR_MGMT_CPU_USAGE_MONITOR_SECTION_ENTER();
    PWR_MGMT_DEBUG_PIN_SET();

    // Wait for an event.
#ifdef SOFTDEVICE_PRESENT
    if (nrf_sdh_is_enabled())
    {
        ret_code_t ret_code = sd_app_evt_wait();
        ASSERT((ret_code == NRF_SUCCESS) || (ret_code == NRF_ERROR_SOFTDEVICE_NOT_ENABLED));
        UNUSED_VARIABLE(ret_code);
    }
    else
#endif // SOFTDEVICE_PRESENT
    {
        // Wait for an event.
        __WFE();
        // Clear the internal event register.
        __SEV();
        __WFE();
    }

    PWR_MGMT_DEBUG_PIN_CLEAR();
    PWR_MGMT_CPU_USAGE_MONITOR_SECTION_EXIT();
    PWR_MGMT_SLEEP_LOCK_RELEASE();
}

In Keil debugging i get the figures, that between breakpoint A and B it's ~40 ns, and between B and A (so next entry of the function) ~223 usec.

Where to look why it's leaving __WFE() so fast again?