DFU over BLE using SMP failing when device is in Error state

RE: DFU over BLE using SMP failing when device is in Error state

Einar Thorsrud — Mon, 05 Feb 2024 11:29:14 GMT

Hi,

That makes sense. If you have an empty while loop without any k_sleep() or similar it will consume all available CPU resources, blocking any lower priority threads.

CAF is used by several of our reference applications, and can definetly be usefull. But compared to with some other SDKs (includign our older nRF5 SDK), you generally do not need that much boiler plate code with Zephyr, which is perhaps why such libraries are not that much used. But to be clear, there is nothing wrong with using CAF modules if those solves an issue for you and it handles of tasks you would otherwise have to implement handling for yourself.

RE: DFU over BLE using SMP failing when device is in Error state

Severin Ferard — Thu, 01 Feb 2024 15:20:46 GMT

Hi,

After conducting further testing, I discovered that removing the for (;;) {} loop in the main function resolves the issue. This loop was responsible for sampling multiple sensors. When encountering a MODULE_STATE_ERROR, the sampling was bypassed, resulting in what seemed like an empty while (true) loop. My understanding is that this perpetually empty loop failed to yield back the system thread, potentially leading to allocation issues, although I'm not entirely certain about the underlying behavior.

Regarding the specific use case, I aim for testers to update the firmware through our mobile application even after a critical error, particularly if the error stemmed from a misconfiguration (e.g., a sensor receiving the wrong address). Since the SWD port is not easily accessible within the testing product, having to dismantle everything to reach the SWD port due to a typo in firmware flashed during a previous DFU would be cumbersome.

I'm somewhat surprised to learn that CAF is not commonly used in consumer applications. To avoid reinventing the wheel, we are leveraging the CAF BLE state module, CAF LED module, and CAF power management module, along with a slightly modified version of the Desktop Battery measurement. I'm curious whether the common approach is to rewrite these functionalities from scratch or if consumer applications typically do not utilize the Application Event Manager framework. I'm relatively new to the nRF Connect ecosystem; hence, my main references were the nRF Desktop sample application, although it may not necessarily exemplify the preferred approach.

RE: DFU over BLE using SMP failing when device is in Error state

Einar Thorsrud — Thu, 01 Feb 2024 13:34:02 GMT

Hi,

The CAF modules are not much used outside of nRF Dekstop so I must admitt I don't ahve much experience with it, but I am having some problems understanding the big picture. This only happens when the state is MODULE_STATE_ERROR right? And this indicate a critical (non-recoverable) error, which also puts the power maner in POWER_STATE_ERROR. Is it expected and desierable to do DFU in that case and not just reset?

Also, out of curiosity, may I ask why you are using CAF?

RE: DFU over BLE using SMP failing when device is in Error state

Severin Ferard — Wed, 31 Jan 2024 00:01:58 GMT

Hi Einar,

I tried to create a minimal reproducible exemple, but I couldn't get the DFU over SMP to work. I kept getting the same kind of error as in my app when in an error state. This would then indicate that something is wrong in my configuration ? Here is the MRE:

prj.conf

CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y

CONFIG_NCS_SAMPLES_DEFAULTS=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="HelloWorld"

CONFIG_LOG=y
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_CBPRINTF_FP_SUPPORT=y
CONFIG_ASSERT=y

CONFIG_APP_EVENT_MANAGER=y
CONFIG_CAF=y
CONFIG_HEAP_MEM_POOL_SIZE=4096

CONFIG_BT_SMP=y
CONFIG_CAF_BLE_STATE=y
CONFIG_CAF_BLE_ADV=y

CONFIG_PM_POLICY_CUSTOM=y
CONFIG_CAF_POWER_MANAGER=y
CONFIG_CAF_POWER_MANAGER_EVENTS=y
CONFIG_CAF_POWER_MANAGER_STAY_ON=y
CONFIG_CAF_POWER_MANAGER_TIMEOUT=120

CONFIG_NET_BUF_LOG=y

main.c

#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(main);

#include <app_event_manager.h>
#define MODULE main
#include <caf/events/module_state_event.h>

int main(void)
{
        if (app_event_manager_init())
        {
                LOG_ERR("Application Event Manager not initialized");
        }
        else
        {
                module_set_state(MODULE_STATE_READY);
        }

        for (;;)
        {
        }
}

I get the same behaviour than previously stated; when connected with the nrf Connect App, I can start a dfu update but it get stuck for a while at "Requesting McuMgr parameters..." then at "Requesting bootloader info..." and finally at "Validating", all while the progress stays at 0.00%. In the RTT logs, I keep seeing multiple net_buf_alloc():1258: Failed to get free buffer.

RE: DFU over BLE using SMP failing when device is in Error state

Einar Thorsrud — Mon, 29 Jan 2024 14:51:47 GMT

Hi,

I am not immediately able to see from the log where the buffer is attemted to be allocated, and also not why (seemingly) buffers are not freed, so that you run out of buffers. Can you elaboreate how this happens and perhaps how to reproduce?