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

[Jandyman]

Setting to 2048 doesn't help at all, same symptoms. I can't set to 4096 or I run out of RAM. I tried to figure out how to decrease the stack size to get 636 bytes but is wasn't obvious how to do so. I'm using GNU tools and Eclipse. I'm using SDK12. Even with a sizeof 2048, RTT and logging are chewing up all my memory. I'll try to attach a map file, I'm not exactly sure how to.

[Jandyman]

Setpoint Starter.map

[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