RTT overflow??

[Jandyman]

I've been instrumenting my Nordic app with RTT logging, which has been working great up until now. I use the deferred mode and use nrf_log_push() to queue all dynamic strings. These dynamic strings usually contain strings of hex numbers (e.g. "01 45 fe 23" etc.). Again everything has been working great until now.

But now I need to test with a much larger amount of data being delivered during a connection interval, and I get the crash shown in the screen shot. I've increased SEGGER_RTT_CONFIG_BUFFER_SIZE_UP to 1024 and NRF_LOG_DEFERRED_BUFSIZE to 1024 in sdk_config.h and it doesn't seem to help. These should be large enough to handle the RTT output occurring during one connection interval.

I don't have any idea how to debug the error shown in the attached image. Can you help?

[Jandyman]

I already increased them, as indicated in the original email. How much more should I increase them?

[ketil]

Hi,

Could you try 2048 first and then 4096 if the first does not help? 

Ketil

[run_ar]

Which version of SDK 12? if it's pre 12.2 check this issue.

[Jandyman]

I'm using version 12.3.0, so that is not the problem. It's not quite the same symptom either.

[Krzysztof Chruscinski]

If you are using NRF_LOG_PUSH to dump hex data then i would recommend to use HEXDUMP macros instead (e.g. NRF_LOG_HEXDUMP_INFO). It requires much less processing. Unfortunately, LOG_PUSH has limitations which are exposed when there is increased logger load and I would not recommend to use it.

[Jandyman]

Sorry for the delay. I was working on another deadline. I can't find any real documentation on NRF_LOG_HEXDUMP_INFO. What does the output look like? If I want out like "Tx out: 0f 04 34 ..." do I do one NRF_LOG_INFO for "Tx out: " and follow it with a call to NRF_LOG_INFO? Does NRF_LOG_HEXDUMP_INFO work well with deferred processing?

Also, I've been wondering whether I even need to used deferred log processing. My entire app runs at interrupt low priority, meaning that any important SoftDevice activity will preempt it. If I weren't doing deferred processing I wouldn't need to use NRF_LOG_PUSH

[run_ar]

Hex dump would probably look something like this. I think only deferred logging is recommended.