RTT not appearing in modified ble_app_uart example

[jake11212]

    Hello,

I have been developing software on the ble_app_uart example in Segger Embedded Studio with sdk 17.0.2.  The example has RTT enabled but I noticed when I try to use RTT in my modified version that no RTT shows up in the debugging window.  I added various libraries and changed the config file, but did not remove anything or turn off anything in the config file from the example.  I wasn't sure how to troubleshoot this and was wondering what potential problems might be interfering with RTT outputs in the debugging terminal.  Here is my main() code, I can add more if necessary.  

int main(void)
{
    bool erase_bonds;
    ret_code_t rc;

    // Initialize.
    twi_init();
    uart_init();
    log_init();
    timers_init();
    buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();


    /* Register first to receive an event when initialization is complete. */
    (void) fds_register(fds_evt_handler);


    rc = fds_init();
    APP_ERROR_CHECK(rc);

    /* Wait for fds to initialize. */
    wait_for_fds_ready();

    // Start execution.
    printf("\r\nUART started.\r\n");



    //turn on LED3 while on and not in sleep mode
    nrf_gpio_cfg_output(LED2);
    nrf_gpio_pin_clear(LED2);

    NRF_LOG_INFO("Debug logging for UART over RTT started.");



    //button press waits for a button press event or times out and goes to sleep mode if no button press is received in 15 seconds
   
    
    buttonPress(); 

    nrf_delay_ms(100);

    advertising_start(); 

    //advertise for 15 seconds then try to send the data
    nrf_delay_ms(5000);

    //SendTime sends the entire memory, should add a condition to make sure that it's connected to BLE, potentially only send new entries etc.
    SendTime(); 

    //wait 5 seconds after sending the data before entering sleep mode, just here to give time to read in devtools for debugging
    nrf_delay_ms(5000);

    sleep_mode_enter_wakeup_enabled();
    
   


    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
    }
}

[Simonr]

Hi Jake

It took a minute to get the device up and running due to the paths you mentioned, but it was easy enough to remedy on my end when I knew. However, I had some trouble building due to this function in your main.c:

 
  switch(writeBool) 
  { 
     case 0 : 
        snprintf(intermediate, sizeof(intermediate), "S: %x:%x:%d %x/%x/%x", rx_data[2], rx_data[1], rx_data[0], rx_data[5], rx_data[4], rx_data[6]);
        break;

     case 1 : 
        snprintf(intermediate, sizeof(intermediate), "E: %x:%x:%d %x/%x/%x", rx_data[2], rx_data[1], rx_data[0], rx_data[5], rx_data[4], rx_data[6]);
        break;

     default :
        break;
  } 

First off, I get a warning because the switch condition has a boolean value, and tit seems like the snprintf functions are interfering with the way SEGGER_RTT_Syscalls_SES.c does RTT. If I commented this function out and set the RETARGET_ENABLED define in sdk_config.h to 0 on my end, RTT seems to work fine in the RTT Viewer, as it prints the wake up process every few seconds:

I think you need to rework this function as it seems to be the culprit to why the RTT viewer doesn't work. Please note that I didn't get the example running while using this function, so what changes did you make to other files, like the SEGGER_RTT_Syscalls_SES.c to get it to run on your end? 

Best regards,

Simon

[jake11212]

I changed RETARGET_ENABLED to 0 and this fixed it, RTT is now working, thanks so much for working with me for so long!

What does RETARGET_ENABLED actually do?  I checked the documentation page but there wasn't a description for it.

I wasn't getting any issues on my end with the bool switch statement or snprintf, and I didn't make any changes to SEGGER_RTT_Syscalls_SES.c to get it to run on my end so I'm not sure why it caused issues for you.  I can look into it more if you'd like but my main problem is solved.

Simonr said:

It took a minute to get the device up and running due to the paths you mentioned, but it was easy enough to remedy on my end when I knew. However, I had some trouble building due to this function in your main.c:

This is outside the scope of the question, but how do you avoid this issue with the paths so that it can build purely from within the SDK?