SparkFun Pro nRF52840 Mini does not send serial using NRF_LOG

[aplatts]

Hi

I'm using a SparkFun Pro nRF52840 Mini which has a UART on PIN 17(TX) and 15(RX). I've written a very simple piece of code to blink the onboard LED on and off and to write to NRF_LOG as a basic starting block for application development. I've connected a serial UART to PINs 17 & 15 (tested that this is working using loop back via CoolTerm).

I'm unable to get any output of the serial using NRF_LOG. The application compiles and the LED blinks as requested.

Within sdk_config.h :-

// <e> NRF_LOG_BACKEND_UART_ENABLED - nrf_log_backend_uart - Log UART backend
//==========================================================
#ifndef NRF_LOG_BACKEND_UART_ENABLED
#define NRF_LOG_BACKEND_UART_ENABLED 1
#endif
// <o> NRF_LOG_BACKEND_UART_TX_PIN - UART TX pin 
#ifndef NRF_LOG_BACKEND_UART_TX_PIN
#define NRF_LOG_BACKEND_UART_TX_PIN 17
#endif

main.c :-

#include "nordic_common.h"
#include "boards.h"
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include "app_uart.h"
#include "app_error.h"
#include "nrf_delay.h"
#include "nrf.h"
#include "bsp.h"

#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"

static void log_init(void)
{
    ret_code_t err_code = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(err_code);
    NRF_LOG_INFO(err_code)
    NRF_LOG_DEFAULT_BACKENDS_INIT();
    NRF_LOG_INFO("\r\nbrf_logging_enabled\r\n");
}

int main(void)
{
    /* Configure board. */
    bsp_board_init(BSP_INIT_LEDS);

    // Initialize.
    log_init();

    /* Toggle LEDs. */
    while (true)
    {
        for (int i = 0; i < LEDS_NUMBER; i++)
        {
            bsp_board_led_invert(i);
            nrf_delay_ms(500);
            NRF_LOG_INFO("\r\nChange Stete!!!!!\r\n");
        }
    }
}

[Vidar Berg]

Hi,

NRF_LOG_PROCESS() must be called periodically to send the log messages on the selected backends, assuming you have the "Deferred processing" option enabled. Or is the NRF_LOG_DEFERRED option already disabled in your project?

[aplatts]

Thanks for the feedback

Think I get it, by setting NRF_LOG_DEFERRED to 0 output is processed on event of NRF_LOG_INFO(). This could be disruptive longterm to time sensitive code is it could interfere with CPU time. With NRF_LOG_DEFERRED set to 1, logs will be processed when entering into an idle state.

I have modified my code looking at best practice from the examples within the SDK. Also shifted the LED blink out of the main loop into a separate function, I assume that given there is a 500ms delay between an LED state change that the CPU will at some point drop into an idle state (apologise if this is an incorrect assumption, this is a learning curve for me).

However I can only obtain the log output whilst NRF_LOG_DEFERRED is set to 0

Further advise would be welcomed, main.c :-

#include "nordic_common.h"
#include "boards.h"
#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>
#include "nrf_pwr_mgmt.h"
#include "app_error.h"
#include "nrf_delay.h"
#include "nrf.h"

#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"

void led_flip_flop(void)
{
    /* Toggle LEDs. */
    while (true)
    {
        for (int i = 0; i < LEDS_NUMBER; i++)
        {
            bsp_board_led_invert(i);
            nrf_delay_ms(500);
            NRF_LOG_INFO("\r\nChange State");
        }
    }
}

static void log_init(void)
{
    ret_code_t err_code = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(err_code);
    NRF_LOG_DEFAULT_BACKENDS_INIT();
    NRF_LOG_INFO("\r\nnrf_logging_enabled");
}

static void power_management_init(void)
{
    ret_code_t err_code;
    err_code = nrf_pwr_mgmt_init();
    APP_ERROR_CHECK(err_code);
}

static void idle_state_handle(void)
{
    if (NRF_LOG_PROCESS() == false)
    {
        nrf_pwr_mgmt_run();
    }
}

int main(void)
{
    /* Configure board. */
    bsp_board_init(BSP_INIT_LEDS);

    // Initialize.
    log_init();
    power_management_init();

    // Functions
    led_flip_flop();
    
    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
    }
}

[Vidar Berg]

aplatts said:

Think I get it, by setting NRF_LOG_DEFERRED to 0 output is processed on event of NRF_LOG_INFO(). This could be disruptive longterm to time sensitive code is it could interfere with CPU time. With NRF_LOG_DEFERRED set to 1, logs will be processed when entering into an idle state.

 Yes, you've understood it correctly. I think it's quite common to use in-place logging for embedded projects in general because it's easier to implement.  But as you said, it can have a significant impact on the execution times for code routines that include logging, particularly at lower UART baud-rates. With in-place logging calls to NRF_LOG_* becomes blocking and does not return until the UART transfer is complete.

aplatts said:

I have modified my code looking at best practice from the examples within the SDK. Also shifted the LED blink out of the main loop into a separate function, I assume that given there is a 500ms delay between an LED state change that the CPU will at some point drop into an idle state (apologise if this is an incorrect assumption, this is a learning curve for me).

I think the problem here is that your program will never reach your main loop because you already have an endless loop in led_flip_flop() (while(1){/*toggle leds forever*/}).  You can try to add the call to "log process" inside your led_flip_flop() function instead:

void led_flip_flop(void)
{
    /* Toggle LEDs. */
    while (true)
    {
        for (int i = 0; i < LEDS_NUMBER; i++)
        {
            bsp_board_led_invert(i);
            nrf_delay_ms(500);
            NRF_LOG_INFO("\r\nChange State");
            NRF_LOG_PROCESS();
        }
    }
}

[aplatts]

Thanks again, by adding the while(true) I can see that Idle state will never be reached.

I'm going to experiment with moving the LED flip-flop call to be processor interrupt driven. I assume this will allow the process to enter into an idle state in-between interrupt events and therefore enabling logs to be processed. Therefore allowing the program to enter into the main loop.