I have an existing Application, that is not a direct copy of an SDK example, as we are using CMake for our builds and because I don't want to copy an sdk_config.h file, but want to use the app_config.h feature for easier updating the SDK later.
To figure out some bonding / paring issues, I want to enable logging. I would love to use RTT for logging and here is the set of C Macros I've defined in app_config.h (I'm certain that app_config.h is included by sdk_config.h and that DEBUG is set):
#if defined DEBUG #define NRF_PM_DEBUG 1 #define NRF_LOG_ENABLED 1 #define NRF_LOG_BACKEND_RTT_ENABLED 1 #define NRF_LOG_BACKEND_SERIAL_USES_RTT 1 #define NRF_LOG_DEFAULT_LEVEL 100 #define NRF_LOG_BUFSIZE 1024 #define NRF_LOG_DEFERRED 1 #define SEGGER_RTT_CONFIG_BUFFER_SIZE_UP 512 #define SEGGER_RTT_CONFIG_MAX_NUM_UP_BUFFERS 2 #define SEGGER_RTT_CONFIG_BUFFER_SIZE_DOWN 16 #define SEGGER_RTT_CONFIG_MAX_NUM_DOWN_BUFFERS 2 // <i> The following modes are supported: // <i> - SKIP - Do not block, output nothing. // <i> - TRIM - Do not block, output as much as fits. // <i> - BLOCK - Wait until there is space in the buffer. // <0=> SKIP // <1=> TRIM // <2=> BLOCK_IF_FIFO_FULL #define SEGGER_RTT_CONFIG_DEFAULT_MODE 0 #define BLE_BAS_CONFIG_LOG_ENABLED 1 #endif
I don't see any loggings, but I see that the attempt to log leads to an endless loop:
(gdb) c
Continuing.
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0002a294 in log_skip () at /Users/todi/bloomlife/sensor-blp/src/nordic/nRF5_SDK/components/libraries/log/src/nrf_log_frontend.c:354
354 if (invalid_packets_omit(p_header, &rd_idx))
(gdb) bt
#0 0x0002a294 in log_skip () at /Users/todi/bloomlife/sensor-blp/src/nordic/nRF5_SDK/components/libraries/log/src/nrf_log_frontend.c:354
#1 0x0002a466 in buf_prealloc (content_len=4, p_wr_idx=0x2000fc48, std=true)
at /Users/todi/bloomlife/sensor-blp/src/nordic/nRF5_SDK/components/libraries/log/src/nrf_log_frontend.c:458
#2 0x0002a54a in std_n (severity_mid=983043, p_str=0x421d4 "Peer data updated in flash: peer_id: %d, data_id: %s, action: %s%s",
args=0x2000fc70, nargs=4) at /Users/todi/bloomlife/sensor-blp/src/nordic/nRF5_SDK/components/libraries/log/src/nrf_log_frontend.c:544
#3 0x0002a688 in nrf_log_frontend_std_4 (severity_mid=983043,
p_str=0x421d4 "Peer data updated in flash: peer_id: %d, data_id: %s, action: %s%s", val0=0, val1=269636, val2=269680, val3=270788)
at /Users/todi/bloomlife/sensor-blp/src/nordic/nRF5_SDK/components/libraries/log/src/nrf_log_frontend.c:615
#4 0x0002258c in pm_handler_pm_evt_log (p_pm_evt=0x2000fd8c)
at /Users/todi/bloomlife/sensor-blp/src/nordic/nRF5_SDK/components/ble/peer_manager/peer_manager_handler.c:541
I expect, that some kind of frontend - backend queue exists and that maybe the frontend is removing elements, where the queue gets full. But here, the log_skip() function is looping over invalid_packets_omit(), which always returns true and so the loop never terminates. invalid_packets_omit() finds always p_header->base.generic.in_progress == 1 and so always returns true. I wonder, how this expression should become false!?
p_header inside log_skip() stays always the same, even with an increasing rd_idx as mask is 0.
I'm running the log-process from within my main loop:
while (1 + 1 == 2) {
if (NRF_LOG_PROCESS() == false)
{
nrf_pwr_mgmt_run();
interface.handle_events();
}
}
What could cause this loop? Is there something obvious wrong with my configuration?
best regards,
Torsten
