No log in rtt viewer but segger yes

Hi,

I have no log using the segger rtt viewer, but when I start Segger in debug mode I have logs.
I'm using an NRF52840 with NRF SDK 17 and MESH SDK 5.0.0.

My logs init :

static void _log_init(void)
{
    ret_code_t err_code = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(err_code);
    NRF_LOG_DEFAULT_BACKENDS_INIT();
}

int main(void)
{
    // Init des logs
    _log_init();

    ...
    
    for (;;)
    {
        watchdog_feed();

        ...
        
        UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());
        nrf_pwr_mgmt_run();
    }
}

The rtt viewer output:

 *

The appconfig :

/** Configuration for the BLE SoftDevice support module to be enabled. */
#define NRF_SDH_ENABLED                   1
#define NRF_SDH_BLE_ENABLED               1
#define NRF_SDH_SOC_ENABLED               1
#define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 1
#define NRF_SDH_BLE_SERVICE_CHANGED       1
#define NRF_BLE_CONN_PARAMS_ENABLED       1
#define NRF_SDH_BLE_VS_UUID_COUNT         4
#define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE   1772


// LFCLOCK Config
#define NRF_SDH_CLOCK_LF_SRC              0 // Select RC source
#define NRF_SDH_CLOCK_LF_RC_CTIV          16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV     16
#define NRF_SDH_CLOCK_LF_ACCURACY         1

#define UART_ENABLED        1
#define UART0_ENABLED       1
#define APP_UART_ENABLED    1
#define UART_LEGACY_SUPPORT 0
#define APP_UART_DRIVER_INSTANCE 0
#define APP_FIFO_ENABLED    1

#define APP_TIMER_ENABLED               1
#define APP_TIMER_KEEPS_RTC_ACTIVE      1
#define APP_TIMER_CONFIG_RTC_FREQUENCY  0

// Enable GPIO support
#define GPIOTE_ENABLED                        1
#define GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS 4

// Disable i2c module
#define TWI_ENABLED           0
#define TWI1_ENABLED          0
#define NRFX_TWIM_ENABLED     0

The log's defines in sdk_config:

// <h> nRF_Log

//==========================================================
// <e> NRF_LOG_BACKEND_RTT_ENABLED - nrf_log_backend_rtt - Log RTT backend
//==========================================================
#ifndef NRF_LOG_BACKEND_RTT_ENABLED
#define NRF_LOG_BACKEND_RTT_ENABLED 1
#endif
// <o> NRF_LOG_BACKEND_RTT_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_RTT_TEMP_BUFFER_SIZE
#define NRF_LOG_BACKEND_RTT_TEMP_BUFFER_SIZE 64
#endif

// <o> NRF_LOG_BACKEND_RTT_TX_RETRY_DELAY_MS - Period before retrying writing to RTT
#ifndef NRF_LOG_BACKEND_RTT_TX_RETRY_DELAY_MS
#define NRF_LOG_BACKEND_RTT_TX_RETRY_DELAY_MS 1
#endif

// <o> NRF_LOG_BACKEND_RTT_TX_RETRY_CNT - Writing to RTT retries.
// <i> If RTT fails to accept any new data after retries
// <i> module assumes that host is not active and on next
// <i> request it will perform only one write attempt.
// <i> On successful writing, module assumes that host is active
// <i> and scheme with retry is applied again.

#ifndef NRF_LOG_BACKEND_RTT_TX_RETRY_CNT
#define NRF_LOG_BACKEND_RTT_TX_RETRY_CNT 3
#endif

// </e>
//==========================================================
// <e> NRF_LOG_ENABLED - nrf_log - Logger
//==========================================================
#ifndef NRF_LOG_ENABLED
#define NRF_LOG_ENABLED 1
#endif
// <h> Log message pool - Configuration of log message pool

//==========================================================
// <o> NRF_LOG_MSGPOOL_ELEMENT_SIZE - Size of a single element in the pool of memory objects.
// <i> If a small value is set, then performance of logs processing
// <i> is degraded because data is fragmented. Bigger value impacts
// <i> RAM memory utilization. The size is set to fit a message with
// <i> a timestamp and up to 2 arguments in a single memory object.

#ifndef NRF_LOG_MSGPOOL_ELEMENT_SIZE
#define NRF_LOG_MSGPOOL_ELEMENT_SIZE 20
#endif

// <o> NRF_LOG_MSGPOOL_ELEMENT_COUNT - Number of elements in the pool of memory objects
// <i> If a small value is set, then it may lead to a deadlock
// <i> in certain cases if backend has high latency and holds
// <i> multiple messages for long time. Bigger value impacts
// <i> RAM memory usage.

#ifndef NRF_LOG_MSGPOOL_ELEMENT_COUNT
#define NRF_LOG_MSGPOOL_ELEMENT_COUNT 8
#endif

// </h>
//==========================================================

// <q> NRF_LOG_ALLOW_OVERFLOW  - Configures behavior when circular buffer is full.


// <i> If set then oldest logs are overwritten. Otherwise a
// <i> marker is injected informing about overflow.

#ifndef NRF_LOG_ALLOW_OVERFLOW
#define NRF_LOG_ALLOW_OVERFLOW 1
#endif

// <o> NRF_LOG_BUFSIZE  - Size of the buffer for storing logs (in bytes).


// <i> Must be power of 2 and multiple of 4.
// <i> If NRF_LOG_DEFERRED = 0 then buffer size can be reduced to minimum.
// <128=> 128
// <256=> 256
// <512=> 512
// <1024=> 1024
// <2048=> 2048
// <4096=> 4096
// <8192=> 8192
// <16384=> 16384

#ifndef NRF_LOG_BUFSIZE
#define NRF_LOG_BUFSIZE 1024
#endif

// <q> NRF_LOG_CLI_CMDS  - Enable CLI commands for the module.


#ifndef NRF_LOG_CLI_CMDS
#define NRF_LOG_CLI_CMDS 0
#endif

// <o> NRF_LOG_DEFAULT_LEVEL  - Default Severity level

// <0=> Off
// <1=> Error
// <2=> Warning
// <3=> Info
// <4=> Debug

#ifndef NRF_LOG_DEFAULT_LEVEL
#define NRF_LOG_DEFAULT_LEVEL 3
#endif

// <q> NRF_LOG_DEFERRED  - Enable deffered logger.


// <i> Log data is buffered and can be processed in idle.

#ifndef NRF_LOG_DEFERRED
#define NRF_LOG_DEFERRED 1
#endif

// <q> NRF_LOG_FILTERS_ENABLED  - Enable dynamic filtering of logs.


#ifndef NRF_LOG_FILTERS_ENABLED
#define NRF_LOG_FILTERS_ENABLED 0
#endif

// <q> NRF_LOG_NON_DEFFERED_CRITICAL_REGION_ENABLED  - Enable use of critical region for non deffered mode when flushing logs.


// <i> When enabled NRF_LOG_FLUSH is called from critical section when non deffered mode is used.
// <i> Log output will never be corrupted as access to the log backend is exclusive
// <i> but system will spend significant amount of time in critical section

#ifndef NRF_LOG_NON_DEFFERED_CRITICAL_REGION_ENABLED
#define NRF_LOG_NON_DEFFERED_CRITICAL_REGION_ENABLED 0
#endif

// <o> NRF_LOG_STR_PUSH_BUFFER_SIZE  - Size of the buffer dedicated for strings stored using @ref NRF_LOG_PUSH.

// <16=> 16
// <32=> 32
// <64=> 64
// <128=> 128
// <256=> 256
// <512=> 512
// <1024=> 1024

#ifndef NRF_LOG_STR_PUSH_BUFFER_SIZE
#define NRF_LOG_STR_PUSH_BUFFER_SIZE 128
#endif

// <o> NRF_LOG_STR_PUSH_BUFFER_SIZE  - Size of the buffer dedicated for strings stored using @ref NRF_LOG_PUSH.

// <16=> 16
// <32=> 32
// <64=> 64
// <128=> 128
// <256=> 256
// <512=> 512
// <1024=> 1024

#ifndef NRF_LOG_STR_PUSH_BUFFER_SIZE
#define NRF_LOG_STR_PUSH_BUFFER_SIZE 128
#endif

// <e> NRF_LOG_USES_COLORS - If enabled then ANSI escape code for colors is prefixed to every string
//==========================================================
#ifndef NRF_LOG_USES_COLORS
#define NRF_LOG_USES_COLORS 0
#endif
// <o> NRF_LOG_COLOR_DEFAULT  - ANSI escape code prefix.

// <0=> Default
// <1=> Black
// <2=> Red
// <3=> Green
// <4=> Yellow
// <5=> Blue
// <6=> Magenta
// <7=> Cyan
// <8=> White

#ifndef NRF_LOG_COLOR_DEFAULT
#define NRF_LOG_COLOR_DEFAULT 0
#endif

// <o> NRF_LOG_ERROR_COLOR  - ANSI escape code prefix.

// <0=> Default
// <1=> Black
// <2=> Red
// <3=> Green
// <4=> Yellow
// <5=> Blue
// <6=> Magenta
// <7=> Cyan
// <8=> White

#ifndef NRF_LOG_ERROR_COLOR
#define NRF_LOG_ERROR_COLOR 2
#endif

// <o> NRF_LOG_WARNING_COLOR  - ANSI escape code prefix.

// <0=> Default
// <1=> Black
// <2=> Red
// <3=> Green
// <4=> Yellow
// <5=> Blue
// <6=> Magenta
// <7=> Cyan
// <8=> White

#ifndef NRF_LOG_WARNING_COLOR
#define NRF_LOG_WARNING_COLOR 4
#endif

Regards

Parents
  • Hi,

    I see from the RTT log in the screenshot that it is from your bootloader. Is the issue that you are not getting RTT logging from the application (except for when debugging)? If so, that is a common issue, and is related to having two separate RTT buffers. If the RTT Viewer finds the buffer for the bootloader first, it will not continue to search for the buffer used by the application. One way to handle this is to specify where the RTT buffer is.

    If the application overwrites the RTT control block (identified by the magic string "SEGGER RTT") that was used by the bootloader, and you then start the RTT viewer, it would only find the application RTT control block.

    However, if the application does not overwrite the RTT control block from the bootloader, then the RTT Viewer might find the control block used by the bootloader. This depends on where the linker places things, and can differ between builds, toolchains, etc. So as long as you have two independent and automatically placed RTT control blocks this will be unpredictable.

    Update: I tested this, and to find the RTT control block address manually you can dump the RAM like this (adjust the size for the amount of RAM on your device):

    nrfjprog --memrd 0x20000000 --n 0x10000 > ram_dump.txt

    Then search for "SEGGER RTT" in the dump. This could be spread across multiple lines, so perhaps just "SEGGER" or "RTT". On my test I found the block here:

    0x20002260: EFDECDBC 030201F0 0000C304 47474553   |............SEGG|
    0x20002270: 52205245 00005454 00000000 00000002   |ER RTT..........|

    Which means that the RTT control block is at 0x2000226C in this case. Then, use RTT Viewer, check the "Address" radio button, and enter the address, and you will be able to read the RTT log.

Reply
  • Hi,

    I see from the RTT log in the screenshot that it is from your bootloader. Is the issue that you are not getting RTT logging from the application (except for when debugging)? If so, that is a common issue, and is related to having two separate RTT buffers. If the RTT Viewer finds the buffer for the bootloader first, it will not continue to search for the buffer used by the application. One way to handle this is to specify where the RTT buffer is.

    If the application overwrites the RTT control block (identified by the magic string "SEGGER RTT") that was used by the bootloader, and you then start the RTT viewer, it would only find the application RTT control block.

    However, if the application does not overwrite the RTT control block from the bootloader, then the RTT Viewer might find the control block used by the bootloader. This depends on where the linker places things, and can differ between builds, toolchains, etc. So as long as you have two independent and automatically placed RTT control blocks this will be unpredictable.

    Update: I tested this, and to find the RTT control block address manually you can dump the RAM like this (adjust the size for the amount of RAM on your device):

    nrfjprog --memrd 0x20000000 --n 0x10000 > ram_dump.txt

    Then search for "SEGGER RTT" in the dump. This could be spread across multiple lines, so perhaps just "SEGGER" or "RTT". On my test I found the block here:

    0x20002260: EFDECDBC 030201F0 0000C304 47474553   |............SEGG|
    0x20002270: 52205245 00005454 00000000 00000002   |ER RTT..........|

    Which means that the RTT control block is at 0x2000226C in this case. Then, use RTT Viewer, check the "Address" radio button, and enter the address, and you will be able to read the RTT log.

Children
  • Hi, thanks for your answer.

    I have tried your command but I don't have app logs inside.

    I only found bootloader logs.

    When I tried to use 0x2000226C address in RTT viewer, no logs

    ram_dump.txt

  • neicureuil said:
    When I tried to use 0x2000226C address in RTT viewer, no logs

    That number was just relevant for my example. Looking at your ram_dump.txt there is an RTT buffer at a different location. Snippet of the relevant part:

    0x20006240: 00000000 00000000 00000000 47474553   |............SEGG|
    0x20006250: 52205245 00005454 00000000 00000002   |ER RTT..........|

    So the RTT block here starts at 0x2000624C.

    I cannot say if this is from your bootloader or app though, but if you have RTT logging enabled in both and only see one and this is when the app is running, it seems likely that the bootloader RTT block has been overwritten and this is for the app. However, as it is just one, the RTT viewer would also be able to find this automatically. So it could also be that there is an other issue in this case. If so, please elaborate a bit more about the issue.

Related