This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ERROR = 0xDEADBEEF in nrf_log_frontend.c:328 while running a ble_app_uart based project.

Hello,
My software project is based on the ble_app_uart, and after doing some initial timer, PWM and SAADC initialisation tasks, the main loop of ble_app_uart runs for a while (typ. 20 seconds) in debug before hitting an assertion and stopping.

The output in the debug window looks like:

Logs dropped (3)
<info> app: 166
Logs dropped (3)
<info> app: 167
Logs dropped (7)
<info> app: 167
<error> app: ERROR 3735928559 [Unknown error code] at C:/Nordic_Semi/nRF5_SDK_15.0.0_a53641a/components/libraries/experimental_log/src/nrf_log_frontend.c:328
PC at: 0x00030383

It should be noted that the ERROR 3735928559  = 0xDEADBEEF
I have no idea what the "Logs dropped" or "<info> app:" messages refer to, although that wold be nice to know.

I am using the Nordic nRF52840 DK (PCA10056), with nRF5_SDK_15, powered by its USB cable. (no battery)

The error location nrf_log_frontend.c:328 refers to the following (undocumented?) sdk code, which contains the problematic ASSERT statement.:

/**
 * Function examines current header and omits pushed strings and packets which are in progress.
 */
static bool invalid_packets_pushed_str_omit(nrf_log_header_t const * p_header, uint32_t * p_rd_idx)
{
    bool ret = false;
    if ((p_header->base.generic.type == HEADER_TYPE_PUSHED) || (p_header->base.generic.in_progress == 1))
    {
        if (p_header->base.generic.in_progress == 1)
        {
            switch (p_header->base.generic.type)
            {
            case HEADER_TYPE_STD:
                *p_rd_idx += (HEADER_SIZE + p_header->base.std.nargs);
                break;
            case HEADER_TYPE_HEXDUMP:
                *p_rd_idx += (HEADER_SIZE + p_header->base.hexdump.len);
                break;
            default:
                ASSERT(0);
                break;
            }
        }
        else
        {
            *p_rd_idx +=
                    (PUSHED_HEADER_SIZE + p_header->base.pushed.len + p_header->base.pushed.offset);
        }
        ret = true;
    }
    return ret;
}



Can anyone shed some light on what is going on, why it asserts, and what these debug messages mean?

  • Hi,

    You will get "Logs dropped" when the internal circular log buffer is full. 

    Are you doing alot of logging? From the log that you have posted, it seems like are printing alot of numbers ?

    If you are using UART as logger backend, you could try to use RTT instead. Set NRF_LOG_BACKEND_RTT_ENABLED to 1 in sdk_config.h, and NRF_LOG_BACKEND_UART_ENABLED to 0.

    Note that this assert will be removed in the next upcoming SDK version.

    Update: SDK 15.1 is now released. You can download it from this link.

     

     

     

  • Hi,
    I'm not trying to log anything! I didn't ask it to log anything. I have no idea how logging even works in this software or how to enable or disable that feature.
    This is just the output of the Nordic UART sample code, and I have no idea how the code works internally.
    I'm just reporting what shows up in the debug windows, and I am asking why it stops working after a short while.
    I will try and re-compile with the updated SDK 15.1, and see if that magically fixes it.

  • Hi,

    I have no idea how logging even works in this software or how to enable or disable that feature.

    You can read about how the logger works here. If you want to disable the log, you need to set NRF_LOG_ENABLED to 0 in sdk_config.h

    The ble_app_uart example will print the data received over BLE on the UART module. It's therefore recommended to use RTT as backend for the logger. 

  • Hi,
    Well, I have now updated my project to use SDK 15.1, (which was ridiculously difficult to do as the project files hard-code the full-path of every included file to the SDK 15.0 folders).
    I also had to manually update sections of the sdk_config.h file based on an example copy in the SDK 15.1, just to be able to compile the logging library. (Also, a number of the SDK library names had changed as they were no longer "experimental", so that caused some confusion and delay).
    NRF_LOG_ENABLED seems to be set to 0 now, because I no longer see a logging window, but hey, the good news is that the code no longer chokes on an assertion after ~20 seconds of run time.
    For now, I think we will call that a WIN.
    Thank you.

Related