• State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 74 subscribers
  • Views 1133 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 284274
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Ways of logging data while debugging

Giovani_Giorgio

Hi guys, I am fairly new to nRF and I try to understand the ways that data can be displayed to the terminal emulator.

So far, I have noticed that there are four different ways(!!!) to do so. Please correct me if I am wrong

1. Printf()  function

2. NRF_LOG_INFO() function with RTT backend

3. NRF_LOG_INFO() function with UART backend

4. RTT communication

First of all what RTT or UART backend means?

Also, how are those configurations selected /activated and where do I see the data if use each one

I understand that the nRF52840 on the DK communicates with the onboard debugger uC through UART and from there the debugger communicates with the PC through USB port. Correct?

I also understand that the nRF52840 is programmed via jlink through the debugger uC but I don't understand  how all those protocols are used and when with respect to the previous 4 ways of displaying data during debugging

Since I am really confused  could someone give a simple explanation of how these things work or is there any fundamental guide including all these variations?

Thanks

Parents
  • +1

    Hi,

    So far, I have noticed that there are four different ways(!!!) to do so. Please correct me if I am wrong

    1. Printf()  function

    2. NRF_LOG_INFO() function with RTT backend

    3. NRF_LOG_INFO() function with UART backend

    4. RTT communication

    There is a lot more alternatives, but I can't list all here (some alternatives are USB CDC ACM, NRF_CLI, UART driver/library/libUARTE, etc). The number of methods all comes down to the desired API abstraction level or low-level access to HW layers. There is no difference in the physical way data are transferred between the chip and the terminal when using alternative 1/3 or 2/4, it is just different levels of abstraction between the HW and the application. For logging, NRF_LOG is the preferred library for passing log strings from the chip to a terminal. It supports different backends, log levels, deferred log processing, along with other features you can read more about in the documentation.

    First of all what RTT or UART backend means?

    Many of our libraries are written with a frontend/backend architecture. Where the frontend interfaces with the application code with a static API, multiple backends can be configured and enabled to process the requests from the frontend. In the NRF_LOG library, different backends are supported as physical transport layers between the chip and the receiver terminal.

    Also, how are those configurations selected /activated and where do I see the data if use each one

    1. printf() is a standard C function for formatting strings and pass this to stdout. In nRF5 SDK, there is a Retarget layer for stdio functions which overrides the default stdio target and pass the strings over UART (through app_uart library). This requires app_uart to be initialized first. See UART Example how this is enabled/configured/used in an application.

    2. The RTT backend for NRF_LOG can be enabled by setting the sdk_config.h symbol NRF_LOG_BACKEND_RTT_ENABLED. If the required source files and headers are included, and NRF_LOG_ENABLED is set in your sdk_config.h file, you can initialize the logger and backend in code using the following macros:

    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
NRF_LOG_DEFAULT_BACKENDS_INIT();

    3. Same as above, but with NRF_LOG_BACKEND_UART_ENABLED symbol.

    4. See this blog post. The Segger RTT source files can be found in nRF5_SDK_17.1.0_ddde560\external\segger_rtt.

    I understand that the nRF52840 on the DK communicates with the onboard debugger uC through UART and from there the debugger communicates with the PC through USB port. Correct?

    Yes, correct. See Virtual COM port.

    I also understand that the nRF52840 is programmed via jlink through the debugger uC but I don't understand  how all those protocols are used and when with respect to the previous 4 ways of displaying data during debugging

    RTT works over the SWD interface, which is the same interface used for programming the chip. The interface MCU on the DK runs a firmware that supports send and receive data over SWD, sending and receiving data over USB from a computer, and sending/receiving UART data from the nRF5x chip.

    Since I am really confused  could someone give a simple explanation of how these things work or is there any fundamental guide including all these variations?

    Hope my answers help clear up your confusions!

    Best regards,
    Jørgen

Reply
  • +1

    Hi,

    So far, I have noticed that there are four different ways(!!!) to do so. Please correct me if I am wrong

    1. Printf()  function

    2. NRF_LOG_INFO() function with RTT backend

    3. NRF_LOG_INFO() function with UART backend

    4. RTT communication

    There is a lot more alternatives, but I can't list all here (some alternatives are USB CDC ACM, NRF_CLI, UART driver/library/libUARTE, etc). The number of methods all comes down to the desired API abstraction level or low-level access to HW layers. There is no difference in the physical way data are transferred between the chip and the terminal when using alternative 1/3 or 2/4, it is just different levels of abstraction between the HW and the application. For logging, NRF_LOG is the preferred library for passing log strings from the chip to a terminal. It supports different backends, log levels, deferred log processing, along with other features you can read more about in the documentation.

    First of all what RTT or UART backend means?

    Many of our libraries are written with a frontend/backend architecture. Where the frontend interfaces with the application code with a static API, multiple backends can be configured and enabled to process the requests from the frontend. In the NRF_LOG library, different backends are supported as physical transport layers between the chip and the receiver terminal.

    Also, how are those configurations selected /activated and where do I see the data if use each one

    1. printf() is a standard C function for formatting strings and pass this to stdout. In nRF5 SDK, there is a Retarget layer for stdio functions which overrides the default stdio target and pass the strings over UART (through app_uart library). This requires app_uart to be initialized first. See UART Example how this is enabled/configured/used in an application.

    2. The RTT backend for NRF_LOG can be enabled by setting the sdk_config.h symbol NRF_LOG_BACKEND_RTT_ENABLED. If the required source files and headers are included, and NRF_LOG_ENABLED is set in your sdk_config.h file, you can initialize the logger and backend in code using the following macros:

    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
NRF_LOG_DEFAULT_BACKENDS_INIT();

    3. Same as above, but with NRF_LOG_BACKEND_UART_ENABLED symbol.

    4. See this blog post. The Segger RTT source files can be found in nRF5_SDK_17.1.0_ddde560\external\segger_rtt.

    I understand that the nRF52840 on the DK communicates with the onboard debugger uC through UART and from there the debugger communicates with the PC through USB port. Correct?

    Yes, correct. See Virtual COM port.

    I also understand that the nRF52840 is programmed via jlink through the debugger uC but I don't understand  how all those protocols are used and when with respect to the previous 4 ways of displaying data during debugging

    RTT works over the SWD interface, which is the same interface used for programming the chip. The interface MCU on the DK runs a firmware that supports send and receive data over SWD, sending and receiving data over USB from a computer, and sending/receiving UART data from the nRF5x chip.

    Since I am really confused  could someone give a simple explanation of how these things work or is there any fundamental guide including all these variations?

    Hope my answers help clear up your confusions!

    Best regards,
    Jørgen

Children
  • 0 in reply to Jørgen Holmefjord

    Hi, thank you for the detailed answer.

    Jørgen Holmefjord said:
    Many of our libraries are written with a frontend/backend architecture. Where the frontend interfaces with the application code with a static API, multiple backends can be configured and enabled to process the requests from the frontend. In the NRF_LOG library, different backends are supported as physical transport layers between the chip and the receiver terminal.

    So, if I understand correctly, the NRF_LOG library is the frontend that I use in my app code and backend RTT or UART are the ways that the nRF52840 exchanges data with the debugger uController and from there to the DK USB that is connected to the debugger(?) .

    Also, if I want to use the nRF uart for communication with another external peripheral like a GPS module I can disable the UART backend and enable only the RTT backend ?

    Very helpful answer indeed!!!
    Thank you so much!

  • 0 in reply to Jørgen Holmefjord
    Giovani_Giorgio said:
    So, if I understand correctly, the NRF_LOG library is the frontend that I use in my app code and backend RTT or UART are the ways that the nRF52840 exchanges data with the debugger uController and from there to the DK USB that is connected to the debugger(?) .

    Yes, that is correct!

    Giovani_Giorgio said:
    Also, if I want to use the nRF uart for communication with another external peripheral like a GPS module I can disable the UART backend and enable only the RTT backend ?

    Yes, that is one alternative. Another alternative (given that you are using nRF52840 or nRF52833) is to use the second UARTE instance (UARTE1) to communicate with the external device, through libUARTE/UART driver/app_uart, and keep the logging enabled over UARTE0 instance.

Related
Terms of service