This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF52840 802.15.4 De-init hangs in "while (nrf_clock_lf_is_running())" loop at LFCLK stop task.

I have a problem, like this fellow engineer here, but the solution is not applying for me.

 More specifically here our function calls from application is like this:

void nrf_802154_deinit(void) {
    nrf_802154_timer_sched_deinit();
    nrf_802154_timer_coord_uninit();
    nrf_802154_temperature_deinit();
    nrf_802154_rsch_uninit();
    nrf_802154_random_deinit();
    nrf_802154_lp_timer_deinit();
    nrf_802154_clock_deinit();
    nrf_802154_core_deinit();
}

void nrf_802154_clock_deinit(void) {
    nrf_drv_clock_uninit();
}

void nrf_drv_clock_uninit(void) {
    ASSERT(m_clock_cb.module_initialized);
    nrfx_clock_disable();
    nrfx_clock_uninit();
    m_clock_cb.module_initialized = false;
}

void nrfx_clock_uninit(void) {
    NRFX_ASSERT(m_clock_cb.module_initialized);
    nrfx_clock_lfclk_stop();
    nrfx_clock_hfclk_stop();
    m_clock_cb.module_initialized = false;
    NRFX_LOG_INFO("Uninitialized.");
}

void nrfx_clock_lfclk_stop(void) {
    NRFX_ASSERT(m_clock_cb.module_initialized);
    nrf_clock_task_trigger(NRF_CLOCK_TASK_LFCLKSTOP);
    while (nrf_clock_lf_is_running()) {}
}
 

Sure, the problem is Watchdog, Not stopping the LFCLK fix's the situation as below:

 Proposed fix is:

void nrfx_clock_uninit(void) {
    NRFX_ASSERT(m_clock_cb.module_initialized);
#if !NRFX_CHECK(NRFX_WDT_ENABLED)
    // Watchdog is still using the LFCLK,
    // and that's why the while loop will stuck if we call this function.
    nrfx_clock_lfclk_stop();
#endif
    nrfx_clock_hfclk_stop();
    m_clock_cb.module_initialized = false;
    NRFX_LOG_INFO("Uninitialized.");
}
 

I would be happy if Nordic engineers officially confirm my observation, and suggest a way if there is a reliable solution here or proposed fix is good without any side effects.

Parents
  • Hello Torbjorn,

    Thank you for your quick reply.

    No particular reason, when we are calling this nrf_802154_deinit() -> nrfx_clock_uninit(), this function is calling this LF clock disable.

    Our requirement here is we need to take the nRF52840 to the sleep state until we toggle GPIO, we must achieve 4uA sleep current for our product. In that process we are calling this nrf_802154_deinit() to disable or stop all of radio activities and HF clocks associated to the radio.

    Here is the function from where we are calling this nrf_802154_deinit() upon sleep entry request:

    void system_tidy_handler(void * p_event_data, uint16_t event_size) {
        UNUSED_VARIABLE(p_event_data);
        UNUSED_VARIABLE(event_size);
        // Close uart
        app_uart_close();
    
        // Turn off radio
        nrf_radio_task_trigger(NRF_RADIO_TASK_DISABLE);
        nrf_802154_deinit();
    
        Gpio_Sleep();
    
        nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF);
    }

    It will be helpful if you share any sleep mode example project for the 802.15.4 Thread stack, I did not found any in the "nRF5_SDK_Thread_Zigbee_4.1".

    Regards, Pratap

  • Hi Pratap

    Less than 4uA should be possible both in system ON idle (with RTC running) or in system off, but if you are able to use GPIO wakeup and don't need very fast wakeup response then using system OFF is a good option. 

    If you are planning to enter system OFF you don't really have to worry about stopping the 32kHz clock in the first place. It will be automatically disabled when you enter sleep. 

    Pratap said:
    It will be helpful if you share any sleep mode example project for the 802.15.4 Thread stack, I did not found any in the "nRF5_SDK_Thread_Zigbee_4.1".

    There are no examples in the Thread/Zigbee SDK for showing how to use system OFF unfortunately. All of these examples use the regular sleep mode instead, to allow for more wakeup sources (such as a timer or the radio). 

    Best regards
    Torbjørn

Reply
  • Hi Pratap

    Less than 4uA should be possible both in system ON idle (with RTC running) or in system off, but if you are able to use GPIO wakeup and don't need very fast wakeup response then using system OFF is a good option. 

    If you are planning to enter system OFF you don't really have to worry about stopping the 32kHz clock in the first place. It will be automatically disabled when you enter sleep. 

    Pratap said:
    It will be helpful if you share any sleep mode example project for the 802.15.4 Thread stack, I did not found any in the "nRF5_SDK_Thread_Zigbee_4.1".

    There are no examples in the Thread/Zigbee SDK for showing how to use system OFF unfortunately. All of these examples use the regular sleep mode instead, to allow for more wakeup sources (such as a timer or the radio). 

    Best regards
    Torbjørn

Children
No Data
Related