• State Verified Answer
  • Replies 3 replies
  • Subscribers 67 subscribers
  • Views 1467 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 253512
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

J-Link RTT Viewer application receives logs with high latency

RAlexeev

When I open J-Link RTT Viewer application to see logs of a program with set CONFIG_LOG_BACKEND_RTT, then I see logs' output with some delay, comparing to logs of the same program with set CONFIG_LOG_BACKEND_UART.
As I understand RTT, there's an allocated memory area in microcontroller's RAM and its address is known to J-Link Interface MCU. My program writes logs' strings to this memory area in RAM rather than to UART, and J-Link Interface MCU reads these logs' strings directly from RAM and writes them to virtual terminals on a connected PC. Probably, there's some frequency of reading this memory area in microcontroller RAM. I want to know whether there's an opportunity to decrease the latency of receiving logs from a microcontroller using some configuration variables of J-Link RTT? In the case of CONFIG_LOG_BACKEND_UART I receive logs' output almost immediately to UART, but in the case of CONFIG_LOG_BACKEND_RTT I receive them after some delay. Does someone know a way how to force receiving logs' using J-Link RTT with low latency? If I intensely write logs, then many of them are dropped and some of them are silently lost at all. I don't think that merely increasing CONFIG_SEGGER_RTT_BUFFER_SIZE_UP too much is a fine option.

  • +1

    If you want faster logging/processing you could enable CONFIG_LOG_IMMEDIATE, however, it has some impacts on the performance:

    "It impacts performance of the system since time consuming operations are performed in the context of the log entry (e.g. high priority interrupt)."

    These blogs may also be insightful:

    If you want to decrease the amount of dropped messages, you could try to follow the tips by Einar in this ticket. Even though it is for the nRF5 SDK and not NCS, I think the tips should still be relevant for you.

    Best regards,

    Simon

  • 0 in reply to Simon

    Thank you, Simon, for suggestions. I tried to set an option CONFIG_LOG_IMMEDIATE

    In the case of nRF52840 DK it didn't work because of assertion error:

    Fullscreen CONFIG_LOG_IMMEDIATE_error.txt Download 
    2> /home/roman/ncs/v1.3.0/zephyr/include/toolchain/gcc.h:62:36: error: static assertion failed: "Immediate logging not supported with the software Link Layer"
2> /home/roman/ncs/v1.3.0/zephyr/subsys/bluetooth/common/dummy.c:38:1: note: in expansion of macro 'BUILD_ASSERT'
4> Compiling 'rpa.c'
Build failed


    In the case of nRF5340 PDK I didn't notice any differences in log output speed with CONFIG_LOG_IMMEDIATE or without this option. The same output of printk() function to UART works about immediately, but I see the same log output in J-Link RTT Viewer after a significant delay.

    I will read the recommended blogs and try again to cope with slow log output speed.

  • +1 in reply to RAlexeev

    Hi,

     

    Unfortunately, you cannot log immediately when using bluetooth, as this will introduce interrupt latency (and thus; might affect the runtime behavior of the BLE stack):

    https://github.com/nrfconnect/sdk-zephyr/blob/master/subsys/bluetooth/common/dummy.c#L32-L40

     

    Are you only using printk() to get your logging output, and do not rely on the LOG module? If yes, then you can disable LOG (CONFIG_LOG=n), then use RTT for printk() operations. This shall be printed without a scheduler in the background.

     

    Kind regards,

    Håkon

Related