NRF_LOG_PUSH seems to be outputting invalid data intermittently

RE: NRF_LOG_PUSH seems to be outputting invalid data intermittently

hmolesworth — Wed, 22 Jul 2020 15:30:21 GMT

Quite, you have to add the code for log_is_busy yourself in 15.3 onwards, as i wrote it based on info from this post I quoted for a sample code to add.

dequeue-must-be-atomically-protected-against-re-entry-from-interrupt-context

RE: NRF_LOG_PUSH seems to be outputting invalid data intermittently

g_frenette — Wed, 22 Jul 2020 15:09:53 GMT

Hi!

Thanks for your input and sorry for the late response. The issue you referred to uses SDK 15.2. However, my issue is with SDK 15.3 and m_log_data has no member log_is_busy in my SDK version unless I'm mistaken.

RE: NRF_LOG_PUSH seems to be outputting invalid data intermittently

hmolesworth — Fri, 26 Jun 2020 21:08:08 GMT

Maybe check this out, if not done already:

bool nrf_log_frontend_dequeue(void)
{
    if (buffer_is_empty())
    {
        return false;
    }
    // Note also add atomic flag set before this __DSB() and after this function exits
    // See https://devzone.nordicsemi.com/f/nordic-q-a/39188/nrf_log_frontend_dequeue-must-be-atomically-protected-against-re-entry-from-interrupt-context
    if (nrf_atomic_flag_set_fetch(&m_log_data.log_is_busy))
    {
        return false;
    }

See frontend dequeue interrupt context

RE: NRF_LOG_PUSH seems to be outputting invalid data intermittently

g_frenette — Fri, 26 Jun 2020 18:31:51 GMT

devzone.nordicsemi.com/.../6330.main.c

devzone.nordicsemi.com/.../0385.sdk_5F00_config.h

No problem regarding the delay!

Using SDK 15.2, example USBD_CDC_ACM found in examples/peripheral/usbd_cdc_acm. You can swap de skd_config file by the one attache. Same for main.c. Pressing button 1 on nRF52840-DK will print in the logger and then you will be able to see the behavior reproduced (the end of the string printed in the logger/viewer will regularly be missing). If that's not enough, please notify me, I can send you some more files but I believe you'll have everything you need with these two files.

Thank you for your help!

RE: NRF_LOG_PUSH seems to be outputting invalid data intermittently

Jørgen Holmefjord — Fri, 26 Jun 2020 13:44:40 GMT

Sorry for the slow response. I forgot to include NRF_LOG_STR_PUSH_BUFFER_SIZE in my list.

Can you provide a minimal example that we can use to reproduce this behavior?

RE: NRF_LOG_PUSH seems to be outputting invalid data intermittently

g_frenette — Fri, 29 May 2020 18:00:41 GMT

Hi,

I tested the output from the logger modifying each config you sent and none of them did anything to the output. However, that got me thinking and I went back on this page and read that NRF_LOG_STR_PUSH_BUFFER_SIZE is closely linked to the usage of NRF_LOG_PUSH(). I also tried NRF_LOG_HEXDUMP_INFO and NRF_LOG_RAW_HEXDUMP_INFO. These last two do print properly. However, they print a lot of extra data which makes it not ideal. So I tested extensively with NRF_LOG_STR_PUSH_BUFFER_SIZE and found the following results when outputting incrementing data (the numbers mentioned are those where there is an error printing, so incrementing values not size values):

NRF_LOG_STR_PUSH_BUFFER SIZE	First error	Interval between errors	Last error recorded
512	235	74	975
1024	309	147	1038
2048	309	293	895
4096	601	562	1163
8192	1163	9174	10337

After the last error recorded, the buffer seems to have stabilized and doesn't output any more errors, but I might not be printing enough data. For these tests, the string printed is the following:

NRF_LOG_RAW_INFO("\t\t%s\n", NRF_LOG_PUSH(value));

Also, I tested using a different string for an NRF_LOG_STR_PUSH_BUFFER_SIZE of 512:

NRF_LOG_RAW_INFO("\t%s\n", NRF_LOG_PUSH(value));

And the first error is at 104; with an interval of 86 and the last error at 1043.

Hopefully, that would tell you a bit more. I can always rely on NRF_LOG_RAW_HEXDUMP_INFO but this wouldn't be ideal.

Thank you so much for your help

RE: NRF_LOG_PUSH seems to be outputting invalid data intermittently

Jørgen Holmefjord — Fri, 29 May 2020 14:22:03 GMT

Hi,

There is a lot of configs that you can play around with in your sdk_config.h file to help solve this issue. I'm not sure exactly which one is causing this in your application:

// <o> NRF_LOG_BACKEND_RTT_TEMP_BUFFER_SIZE - Size of buffer for partially processed strings. 
// <i> Size of the buffer is a trade-off between RAM usage and processing.
// <i> if buffer is smaller then strings will often be fragmented.
// <i> It is recommended to use size which will fit typical log and only the
// <i> longer one will be fragmented.

#ifndef NRF_LOG_BACKEND_RTT_TEMP_BUFFER_SIZE
#define NRF_LOG_BACKEND_RTT_TEMP_BUFFER_SIZE 64
#endif

// <h> Log message pool - Configuration of log message pool

//==========================================================
// <o> NRF_LOG_MSGPOOL_ELEMENT_SIZE - Size of a single element in the pool of memory objects. 
// <i> If a small value is set, then performance of logs processing
// <i> is degraded because data is fragmented. Bigger value impacts
// <i> RAM memory utilization. The size is set to fit a message with
// <i> a timestamp and up to 2 arguments in a single memory object.

#ifndef NRF_LOG_MSGPOOL_ELEMENT_SIZE
#define NRF_LOG_MSGPOOL_ELEMENT_SIZE 20
#endif

// <o> NRF_LOG_MSGPOOL_ELEMENT_COUNT - Number of elements in the pool of memory objects 
// <i> If a small value is set, then it may lead to a deadlock
// <i> in certain cases if backend has high latency and holds
// <i> multiple messages for long time. Bigger value impacts
// <i> RAM memory usage.

#ifndef NRF_LOG_MSGPOOL_ELEMENT_COUNT
#define NRF_LOG_MSGPOOL_ELEMENT_COUNT 8
#endif

// </h> 
//==========================================================

// <q> NRF_LOG_ALLOW_OVERFLOW  - Configures behavior when circular buffer is full.
 

// <i> If set then oldest logs are overwritten. Otherwise a 
// <i> marker is injected informing about overflow.

#ifndef NRF_LOG_ALLOW_OVERFLOW
#define NRF_LOG_ALLOW_OVERFLOW 1
#endif

// <o> NRF_LOG_BUFSIZE  - Size of the buffer for storing logs (in bytes).
 

// <i> Must be power of 2 and multiple of 4.
// <i> If NRF_LOG_DEFERRED = 0 then buffer size can be reduced to minimum.
// <128=> 128 
// <256=> 256 
// <512=> 512 
// <1024=> 1024 
// <2048=> 2048 
// <4096=> 4096 
// <8192=> 8192 
// <16384=> 16384 

#ifndef NRF_LOG_BUFSIZE
#define NRF_LOG_BUFSIZE 1024
#endif

// <o> SEGGER_RTT_CONFIG_BUFFER_SIZE_UP - Size of upstream buffer. 
// <i> Note that either @ref NRF_LOG_BACKEND_RTT_OUTPUT_BUFFER_SIZE
// <i> or this value is actually used. It depends on which one is bigger.

#ifndef SEGGER_RTT_CONFIG_BUFFER_SIZE_UP
#define SEGGER_RTT_CONFIG_BUFFER_SIZE_UP 512
#endif

// <o> SEGGER_RTT_CONFIG_MAX_NUM_UP_BUFFERS - Size of upstream buffer. 
#ifndef SEGGER_RTT_CONFIG_MAX_NUM_UP_BUFFERS
#define SEGGER_RTT_CONFIG_MAX_NUM_UP_BUFFERS 2
#endif

// <o> SEGGER_RTT_CONFIG_BUFFER_SIZE_DOWN - Size of upstream buffer. 
#ifndef SEGGER_RTT_CONFIG_BUFFER_SIZE_DOWN
#define SEGGER_RTT_CONFIG_BUFFER_SIZE_DOWN 16
#endif

// <o> SEGGER_RTT_CONFIG_MAX_NUM_DOWN_BUFFERS - Size of upstream buffer. 
#ifndef SEGGER_RTT_CONFIG_MAX_NUM_DOWN_BUFFERS
#define SEGGER_RTT_CONFIG_MAX_NUM_DOWN_BUFFERS 2
#endif

// <o> SEGGER_RTT_CONFIG_DEFAULT_MODE  - RTT behavior if the buffer is full.
 

// <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 

#ifndef SEGGER_RTT_CONFIG_DEFAULT_MODE
#define SEGGER_RTT_CONFIG_DEFAULT_MODE 0
#endif

Best regards,
Jørgen