K_sleep from main function

[levijo]

Hi,

It seems like my system is crushing before going to deep sleep,

I have noticed that if I remove a k_sleep of 500 ms, just before going to deep sleep the system does not crush.

I was wondering if it is allowed to call k_sleep from main function. I know in other rtos is is not allowed since main is not running in a thread context. I would like to know if this the case in zephyr as well

[Hieu]

Hi levijo,

Calling k_sleep() in main() is fine. What kind of deep sleep are you talking about here? Do you have some code snippets?

Hieu

[levijo]

Yes look below:

The last k_sleep before sys_poweroff is the one I'm referring to

enter_deep_sleep:

    if (exit_reason != SYSTEM_EXIT_CODE_RESTART_REQUIRED) {
        LOG_WRN("entering deep sleep ...");

        if (IS_ENABLED(CONFIG_APP_HAL_REGULATOR)) {
            hal_regulator_exit();
        }

#if DT_NODE_HAS_STATUS(DT_INST(0, nordic_qspi_nor), okay)
        const struct device *const qspi_device = DEVICE_DT_GET(DT_INST(0, nordic_qspi_nor));
        if (device_is_ready(qspi_device)) {
            if (pm_device_action_run(qspi_device, PM_DEVICE_ACTION_SUSPEND) < 0) {
                LOG_WRN("could not suspend nordic qspi");
            }
        }
#endif

        if (IS_ENABLED(CONFIG_I2C)) {
            const struct device *const i2c_device = DEVICE_DT_GET(DT_NODELABEL(i2c1));

            if (device_is_ready(i2c_device)) {
                if (pm_device_action_run(i2c_device, PM_DEVICE_ACTION_SUSPEND) < 0) {
                    LOG_WRN("could not suspend i2c1");
                }
            }
        }

        if (IS_ENABLED(CONFIG_SERIAL)) {
            const struct device *const serial_device = DEVICE_DT_GET(DT_CHOSEN(zephyr_console));

            if (device_is_ready(serial_device)) {
                if (pm_device_action_run(serial_device, PM_DEVICE_ACTION_SUSPEND) < 0) {
                    LOG_WRN("could not suspend serial console");
                }
            }
        }

        /* put the system in deep sleep */
        k_sleep(K_MSEC(500));

        sys_poweroff();
 

[Hieu]

I have been trying to look into this error but find very few mentions and no meaningful lead so far.

How did you turn off BLE? And what nRF Connect SDK version are you using?

[levijo]

Hi,

I have found the root cause, it was a bug in our code,

Thank you for your support,

[Hieu]

It's great that you have it working. Records about that warning message is pretty scarce, so if you can, please share what you have found with the community.

[levijo]

The process of shutting down the system (entering deep sleep):

enter_deep_sleep:

    if (exit_reason != SYSTEM_EXIT_CODE_RESTART_REQUIRED) {
        LOG_WRN("entering deep sleep ...");

        if (IS_ENABLED(CONFIG_APP_HAL_REGULATOR)) {
            hal_regulator_exit();
        }

#if DT_NODE_HAS_STATUS(DT_INST(0, nordic_qspi_nor), okay)
        const struct device *const qspi_device = DEVICE_DT_GET(DT_INST(0, nordic_qspi_nor));
        if (device_is_ready(qspi_device)) {
            if (pm_device_action_run(qspi_device, PM_DEVICE_ACTION_SUSPEND) < 0) {
                LOG_WRN("could not suspend nordic qspi");
            }
        }
#endif

        if (IS_ENABLED(CONFIG_I2C)) {
            const struct device *const i2c_device = DEVICE_DT_GET(DT_NODELABEL(i2c1));

            if (device_is_ready(i2c_device)) {
                if (pm_device_action_run(i2c_device, PM_DEVICE_ACTION_SUSPEND) < 0) {
                    LOG_WRN("could not suspend i2c1");
                }
            }
        }

        if (IS_ENABLED(CONFIG_SERIAL)) {
            const struct device *const serial_device = DEVICE_DT_GET(DT_CHOSEN(zephyr_console));

            if (device_is_ready(serial_device)) {
                if (pm_device_action_run(serial_device, PM_DEVICE_ACTION_SUSPEND) < 0) {
                    LOG_WRN("could not suspend serial console");
                }
            }
        }

        /* put the system in deep sleep */
        k_sleep(K_MSEC(500));

        sys_poweroff();

1. suspending QSPI

2. 500 ms delay

3. another task tries to write to flash (using QSPI) - causing a crush

I have moved the delay to be before suspending the QSPI and problem solved

[Hieu]

Many thanks, levijo