This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
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

Command line tracing in Ubuntu

Hi again.

I'm using nRF52 DK board in Ubuntu. I can flash the device with the blinky example (I haven't yet tried the softdevice tough), but I cannot really get any traces out of the SW. I added simple printf to blinky main loop to keep things simple.

JLinkExe -device nrf52 -if swd -speed 4000

SEGGER J-Link Commander V5.10u (Compiled Mar 17 2016 19:06:22) DLL version V5.10u, compiled Mar 17 2016 19:06:19

Connecting to J-Link via USB...O.K. Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Mar 15 2016 18:03:17 Hardware version: V1.00 S/N: 682343799 VTref = 3.300V

Type "connect" to establish a target connection, '?' for help J-Link>connect Device "NRF52" selected.

if I run tstart I get:

Trace could not be started, no trace clock.

What is still missing here?

  • Ok, lets reform the question.

    What is the easiest way to try the tracing under linux? I noticed, that there's pretty much no printf:s in other examples than the uart.

    I managed to get uart traces out (only to terminal, not via any j-link related tool) from putty-example by adding uart config to example:

    const app_uart_comm_params_t comm_params =
    {
      RX_PIN_NUMBER,
      TX_PIN_NUMBER,
      RTS_PIN_NUMBER,
      CTS_PIN_NUMBER,
      APP_UART_FLOW_CONTROL_ENABLED,
      false,
      UART_BAUDRATE_BAUDRATE_Baud38400
    };
     // Initialize.
    
    APP_UART_FIFO_INIT(&comm_params,
                     UART_RX_BUF_SIZE,
                     UART_TX_BUF_SIZE,
                     uart_error_handle,
                     APP_IRQ_PRIORITY_LOW,
                     err_code);
    

    However when I tried this with any soft device example, no trace is outputted properly (some random characters appear to terminal occasionally). The app_trace_init seems to do same thign with higher bus clock, but that's it.

    Is there something in the softdevice that re-routes the uart output? Or is this matter of some makefile setting?

  • To continue my monolog:

    I managed to get some life out of the tracing (altough still not working properly).

    By adding few makefile flags: CFLAGS += -DBSP_UART_SUPPORT CFLAGS += -DENABLE_DEBUG_LOG_SUPPORT (originally I just removed the #ifdef from the app_trace.h & c)

    Also -replaced uart_app.c with uart_app_fifo.c -added INC_PATHS += -I../config/uart_pca10036 -added INC_PATHS += -I../components/libraries/uart

    After this I get trace calls from main loop (this is trace & debugger modified version of ble alert notification example) with 2,5 sec delay: for (;;) { printf("\n looping\n\r"); nrf_delay_ms(2500); power_manage(); }

    And in terminal: looping looping looping

    However if button is pressed (i added only extra traces there) it all goes bad:

    " ����"

    Is this some stack overflow in the cb?

  • Now it works. const app_uart_comm_params_t comm_params = { RX_PIN_NUMBER, TX_PIN_NUMBER, RTS_PIN_NUMBER, CTS_PIN_NUMBER, APP_UART_FLOW_CONTROL_ENABLED, false, UART_BAUDRATE_BAUDRATE_Baud115200 };

    And the main thing was to change the tx buffer size in the file to 2k. apparently the whole system outputs so much trace that it overflows.

Related