Using Percepio TraceAnalzer to debug a FreeRTOS driver2018-11-15T22:19:53+00:00

Home Forums Percepio Using Percepio TraceAnalzer to debug a FreeRTOS driver

Viewing 1 post (of 1 total)
  • Author
    Posts
  • robert.lewis@iMnMicroControl.com
    Participant
    Post count: 2

    Debugging a real time driver is problematic on many levels. The driver must be debugged in its final state without debug code inserted. Code changes can change the deterministic behavior of the driver. Debug break points are useful for determining variable contents and basic design of program flow but also impact the behavior of the driver. For example in a uart driver using an on chip FIFO system, setting a breakpoint  within in a stream will cause any char’s that follow in the stream to be lost. If this is a frame based software design all the determinism related to the frame is also lost.

     

    The solution to these problems is to use TraceAlyzer with the vTracePrintF statement;  vTracePrintF is a formatted print api that uses negligible resources and will stream data over the SWO pin using buffers without impacting the driver performance. Below is an example of code from a driver I wrote that does this vTracePrintF to trace the stream.

     

    if ((UART_S1_RDRF_MASK & UART0->S1) && (UART_C2_RIE_MASK & UART0->C2)){                                                               // Receive data register full

    while(UART0->RCFIFO > 0){                                                                   // unload FIFO char’s received

    (void)UART0->RCFIFO;

    gca_rxBuffer[gps_UartIrqDrvrHandle->u8_rx_buffer_index++] = UART0->D;                                                         // move to local buffer until message complete

    }

    gps_UartIrqDrvrHandle->u32_rx_char_cnt = gps_UartIrqDrvrHandle->u8_rx_buffer_index;

     

    UART0->S2 = UART0->S2 | UART_S2_RXEDGIF_MASK;                                                                                     // clear interrupt

    xTimerChangePeriodFromISR(uartIrqCharTimeOutHandle, pdMS_TO_TICKS( gps_UartIrqDrvrHandle->x_new_period ), &xHigherPriorityTaskWoken);                                      // 1st char resets timer immed, missed char blocks for 1 tick, see last else

     

    vTracePrintF(bt_channel, “uart string: %s”, xTraceRegisterString(gca_rxBuffer) );

     


    Why this driver was difficult to design and implement is that, it that the serial stream is frame based with start and end char terminators but with no way to determine when a loss of stream has occurred apart from a timeout. The timeout mechanism was working as expected but there were assumptions in the design that were incorrect based on when the timeout applied. To trace the flow using breakpoints was impossible, even the hardware logic analyzer could assist only so far. But by inserting  the above vTracePrintF I could see the message formed, which the subsequent state machine was interpreting and failing on. The message was one char short and therefore never parsed as expected. Below is a capture of the TraceAlzyer output used to find the problem. You can see the stream.

     

    vTracePrintF Uart Frame driver

    Robert Lewis

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.