Session 10: Logging

Document created by Gabriela Godinez Employee on Jun 29, 2016
Version 1Show Document
  • View in full screen mode

This video presentation is the tenth installment of the Essentials of MQX RTOS Application Development training course. In this session, you will be introduced to kernel logging.

This training was created by Embedded Access Inc., a Freescale sponsored training provider and proven partner.

Session 10 Course LineLab Outline
  • What is logging?
  • How logs work
  • Use cases for logging
  • Working with light weight logs
  • Working with kernel logging
    • Filtering what is logged
    • Logging MQX function and ISR entries and exits
    • Displaying a log entry
    • Logging task and stack usage
  • Working with full featured logs
  • Creating a Kernel Log
  • Filtering a Klog for context switches, interrupts, and functions
  • Changing the Klog filter
  • Filtering by qualified tasks

 

First, watch the video for Session 10: Kernel Logging.

Then, follow through with the interactive lab assignment below.

SESSION 10: LAB ASSIGNMENT

INTRODUCTION

Logging can be an excellent debugging aid to you, but to be effective you have to be clear on what you are looking for and set up logging accordingly. Knowing what to log is something that comes with experience and familiarity with the features at your disposal. This lab is intended to help you with the familiarization aspect so you can leverage your knowledge when you get to the debug phase of your next project.

OBJECTIVE

The objective of this lab is to learn about the kernel logging facility by enabling kernel logging in the application and experimenting with the various modes of operation.This objective will be accomplished by:

  • Enabling kernel logging in user_config.h
  • Rebuilding the PSP and BSP
  • Creating a kernel log
  • Enabling the kernel log
  • Using task aware debug to examine the kernel log
  • Modifying logging parameters to filter by task
  • Modifying logging parameters to Filter by function group (timers & events)

New functions/ structures you will use:
     _klog_create, _klog_control, _klog_enable_logging_task. _task_get_id

ASSIGNMENT

INITIALIZING THE LOG

    1. Since we are going to be use kernel logging for this lab you'll need to include the klog.h header file and the best place to add this is in main.h.
    2. The first thing we need to do is create the kernel log with a buffer of 2048 bytes using the _klog_create() function. The Health Task is responsible for monitoring the health of the system so it makes sense that this is done here. Since you only have to create the log once of course this call should be done in the initialization section of the Health Task. For now we can define the logging to stop when the buffer gets full.
      cheat.png
      Cheat 10-1.png
    3. Once the log has been created you need to enable kernel logging with the _klog_control() function. To start with, turn on the logging for context switches, all interrupts, the system clock interrupt, and two functions - Time Functions and Interrupt Functions.

      whiteboard.png
      Whiteboard 10-1.jpg
    4. Finally, we need to check if Kernel Logging is enabled in user_config.h for the BSP. In the BSP project you will find user_config.h in the User_Config folder. If you do not see a define for MQX_KERNEL_LOGGING you can add it by right clicking on user_config.h on the left in the Project View window, selecting 'Open With' and selecting 'C/C++ Editor'. You can add into this file:
      #define     MQX_KERNEL_LOGGING        1 

TESTING OUR LOGGING

    1. If you made a change to user_config.h you'll have to compile both the BSP and PSP before compiling the application.
    2. Run your application and ensure that it is running okay by confirming that you're getting print messages to the console. Pause the application (as opposed to killing it) and select the Kernel Logging window in the Task Aware Debugging pull down menu (MQX > Kernel Logging).
    3. Scroll through the log file to confirm that entries for all of the enabled types of logs are observed: Context Switches, Timers, and interrupts.
      results.png
      Results 10-1.png

CHANGING THE LOGGING FILTERS TO ELIMINATE THE INTERRUPT LOGS

    1. You may have noticed that the number of logs from interrupts, in particular system tick interrupts, makes it difficult to find the other logs. If you are debugging an issue this makes it hard to find the data you are looking for and it also fills the log buffer up quite quickly. It would then be a good idea to filter out all logs from interrupts. You can do this by deleting the KLOG_INTERRUPTS_ENABLED and KLOG_SYSTEM_CLOCK_INT_ENABLED from the _klog_control() function call.
    2. Compile your application, run it for a few seconds, and then pause it. Observe the kernel log window again to ensure that the interrupt logs are not present.
      results.png
      Results 10-2.png

FILTER THE LOG BY TASK

    1. Now we want to filter out the logs from tasks except the logs from the Health Task. To do this the _klog_control() function call needs to be updated to enable the task qualified filter. This means that only tasks that have enabled logging specifically in the task code will have log entries related to it logged. Don't forget that any task can fetch their task id number using the _task_get_id() function.
      whiteboard.png
      Whiteboard 10-2.jpg
    2. Compile your application, run it for a few seconds, and then pause it. Observe the kernel log window. You should see context switches to the Health Task being logged but nothing else.
      results.png
      Results 10-3.png

ADDING MESSAGE FUNCTIONS TO THE FILTER

    1. The Health Task is sending messages but in order to see logs related to the sending of messages you would need to add Message Functions to the list of functions being logged. As you guessed by now this is accomplished with an update to the _klog_control() function call.
    2. Again observe the kernel logging window after the application has been compiled and run for a few seconds. You should see a number of logs from message functions.
      whiteboard.png
      Whiteboard 10-3.jpg
      results.png
      Results 10-4.png

LOGGING JUST TIME AND EVENT FUNCTIONS

  1. To change things up we'll look at just the Time and Event Functions. You can remove the logging of Message functions and you can disable the task qualified logging from the Health Task.
    cheat.png
    Cheat 10-2.png
  2. Once this has been tried you should now see a number of entries in the log from lwevents and lwtimers.
    results.png
    Results 10-5.png

Need more help? The full source code for this lab can be found in the 'Lab Source Code' folder here.

Attachments

    Outcomes