Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

May I ask, what's the change of nrf_log in sdk 15.3?

Hi,

I am migrating sdk 15.2 to 15.3. Everything works fine, except the nrf logging. Currently, I am using RTT configuration, with default backend enabled. The code is simple:

// Initialize SDK Logger.

APP_ERROR_CHECK(NRF_LOG_INIT(app_timer_cnt_get));

NRF_LOG_DEFAULT_BACKENDS_INIT();

Things odd is that: the log is dumped in a quite slow speed. It acts like, the logging buffer stored in rnf52840 chip. Without event triggered, they are not dumped into RTT viewer. That is to say, the log is dumped in a very deferred way. The latest logs are always not shown in RTT viewer.

BTW, other code is the same, with usbd enabled and also BLE. The functional thing works fine.

The same code works well under sdk 15.2, with the logging is dumped immediately. 

environment:

j-link 6.40

win7

sdk15.3

Since I can not find a way to debug it, would you please give me some suggestions on this? A list of the nrf_log changes in sdk 15.3 would be fine. I attached my sdk_config.h

Thanks

sdk_config.h

  • Hi

    I compared your config file to a 15.3 config file using RTT, and found 2 differences in the NRF_LOG.

    First the SEGGER_RTT_CONFIG_BUFFER_SIZE_UP value is 1024 in your config file, but 512 in the 15.3 file. Could you try changing this to see if it makes any difference.

    Next, the following code (enabling UART logging) is present in your file, are you using UART for something as well? If not you could try commenting out these defines (I don't think it will matter but it's worth a shot).

    // <e> NRF_LOG_BACKEND_UART_ENABLED - nrf_log_backend_uart - Log UART backend
    //==========================================================
    #ifndef NRF_LOG_BACKEND_UART_ENABLED
    #define NRF_LOG_BACKEND_UART_ENABLED 0
    #endif
    // <o> NRF_LOG_BACKEND_UART_TX_PIN - UART TX pin 
    #ifndef NRF_LOG_BACKEND_UART_TX_PIN
    #define NRF_LOG_BACKEND_UART_TX_PIN 31
    #endif
    
    // <o> NRF_LOG_BACKEND_UART_BAUDRATE  - Default Baudrate
     
    // <323584=> 1200 baud 
    // <643072=> 2400 baud 
    // <1290240=> 4800 baud 
    // <2576384=> 9600 baud 
    // <3862528=> 14400 baud 
    // <5152768=> 19200 baud 
    // <7716864=> 28800 baud 
    // <10289152=> 38400 baud 
    // <15400960=> 57600 baud 
    // <20615168=> 76800 baud 
    // <30801920=> 115200 baud 
    // <61865984=> 230400 baud 
    // <67108864=> 250000 baud 
    // <121634816=> 460800 baud 
    // <251658240=> 921600 baud 
    // <268435456=> 1000000 baud 
    
    #ifndef NRF_LOG_BACKEND_UART_BAUDRATE
    #define NRF_LOG_BACKEND_UART_BAUDRATE 30801920
    #endif
    
    // <o> NRF_LOG_BACKEND_UART_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_UART_TEMP_BUFFER_SIZE
    #define NRF_LOG_BACKEND_UART_TEMP_BUFFER_SIZE 64
    #endif

    Finally, the only changes made to logging between 15.3 and 15.2 are these two that are stated in the SDK15.3 release notes, which are bug fixes: 

    - Fixed an issue where NRF_LOG_INIT(timestamp, frequency) failed to compile if the logger was disabled.
    - Fixed a compilation failure issue when using NRF_LOG_HEXDUMP_WARNING.

    Have you done any changes what so ever between the 15.2 and 15.3 version of your code?

    Please try/check out these differences. I will look further into it if you can't get to the bottom of this issue.

    Best regards,

    Simon

  • Hi Simon,

    Thanks for your suggestions. Bad luck, I tried the ways you mentioned and did not work.

    By investigation, I found SEGGER_RTT_WriteNoLock() is correctly called during the idle task. So it is a problem of fetching log by pc side? I did not dig into the logging module(the logging is only for debugging in my case). Would you please give me some tips on how the log can be fetched by pc? So that I can do more work.

    Thanks,

    Vincent

  • Also, I tried to use SEGGER_RTT_printf API directly to call several times, however, the problem still exists.

    You mentioned the logging in sdk 15.3, would you please let me know which example can do correct logging, please? 

    Thanks

  • Without event triggered, they are not dumped into RTT viewer

    Sounds like this problem:

    https://devzone.nordicsemi.com/f/nordic-q-a/34666/nrf5-sdk-v15-0-0-bug-report-incorrect-use-of-nrf_log_process-in-ble_app_uart-peripheral-example-among-others

    A (the?) symptom of that problem is that the RTT logs do not come out until after some event wakes the process - and then only 1 log comes per event.

  • Hi Awneil,

    Thanks for your reply.  My loop code is as follows. Should not have that issue. Also, please see me comment:

    "By investigation, I found SEGGER_RTT_WriteNoLock() is correctly called during the idle task. So it is a problem of fetching log by pc side? I did not dig into the logging module(the logging is only for debugging in my case). Would you please give me some tips on how the log can be fetched by pc? So that I can do more work."

    I set a breakpoint in NRF_LOG_PROCESS() and debug it step by step and found SEGGER_RTT_WriteNoLock() is correctly called with the latest log. However, the RTT viewer didn't show. Would you please let me know how I debug it further? 

    Thanks,

    Vincent

    static void idle_task(void *p_context)
    {
        // Enter main loop.
        for (;;)
        {
    
    				while (app_usbd_event_queue_process())
    				{
    						/* Nothing to do */
    				}
            /* Handle background and debug events one by one, go to sleep when done. */
            do
            {
    
            }
            while (NRF_LOG_PROCESS());
    
    
            if (run_power_saving) 
            {
                mgmt_run();
            }
    #
        }
    }

Related