Setting "CONFIG_LOG_MODE_OVERFLOW=y" will always print "1 messages droppend" after a period of RTT printing.

[yuanFang]

I am useing NCS v2.6.0. Setting "CONFIG_LOG_MODE_OVERFLOW=y", will always print "1 messages droppend" after a period of RTT printing.
CONFIG_LOG_MODE_OVERFLOW=n will no longer print "1 messages droppend". Why is that?

prj.conf:

CONFIG_LOG=y

CONFIG_USE_SEGGER_RTT=y

CONFIG_LOG_BACKEND_RTT=y

CONFIG_LOG_BACKEND_UART=n

CONFIG_LOG_PRINTK=n

CONFIG_LOG_MEM_UTILIZATION=y

CONFIG_LOG_MODE_OVERFLOW=n

CONFIG_LOG_BACKEND_SHOW_COLOR=y

autoconf.h

#define CONFIG_SEGGER_RTT_BUFFER_SIZE_UP 1024

#define CONFIG_LOG_BUFFER_SIZE 1024

#define CONFIG_LOG_PROCESS_THREAD_STACK_SIZE 2048

[Menon]

Hello,

If you check  CONFIG_LOG_MODE_OVERFLOW you can see that  logging system is configured to overwrite the oldest log messages in the buffer when the buffer becomes full. This means that the buffer continues to accumulate new log messages, but if it becomes full, older messages are dropped to make room for the new ones.

The message "1 message(s) dropped" indicates that a log message was dropped because the buffer ran out of space. When CONFIG_LOG_MODE_OVERFLOW=n: The log system stops logging when the buffer is full, so no messages are dropped, and thus no "1 message dropped" notification appears.

Try increasing the CONFIG_LOG_BUFFER_SIZE.

Kind Regards,

Abhijith

[yuanFang]

Thank you for your reply.

When I increase CONFIG_LOG_BUFFER_SIZE. To 10k, I occasionally get "1 messages droppend".

The following "pf_log_raw()" prints the code, please evaluate if I am at risk

#define NCS_LOG_FLUSH()         while(log_process())
#define pf_log_raw(onoff, ...) do {if (onoff) {LOG_INF(__VA_ARGS__);NCS_LOG_FLUSH();}} while (0);


pf_log_raw(1, "The resume reason: 0x%08x, 0x%x \r", resetReason, NRF_POWER->RESETREAS);

Looking forward to your reply, thank you very much.

yuanFang

[Menon]

Hello,

yuanFang said:

When I increase CONFIG_LOG_BUFFER_SIZE. To 10k, I occasionally get "1 messages droppend"

Increasing the buffer size helps, but if there are high-frequency log bursts or RTT delays, you can still occasionally drop messages.

The macro pf_log_raw() could block the system if RTT is slow, and you still risk dropped messages if the log rate exceeds what RTT can handle, even with immediate flushing.

Optimizing RTT speed, tuning buffer sizes, and reducing logging rates in time-critical code sections could resolve the issue.

Kind Regards,

Abhijith