Main Content

TLC Code Coverage to Aid Debugging

tlcdebug Execute Tutorial Overview

Objective: Learn to use TLC coverage statistics to help identify bugs in TLC code.

Open the Example:

openExample('simulinkcoder/AdviceAboutTLCTutorialsExample')
cd('tlctutorial/tlcdebug')

This tutorial teaches you how to determine whether your TLC code is being executed as expected. Here it uses the same model as for the previous tutorial. As you focus on understanding flow of control in processing TLC files, you don’t need to compile and execute a standalone model, only to look at code. The tutorial proceeds as follows:

  1. Getting Started — Why and how to analyze TLC coverage

  2. Open the Model and Generate Code — Read a coverage log file

Getting Started

The Code Generation > Debug pane provides the option Start TLC coverage when generating code. Selecting it results in a listing that documents how many times each line in your TLC source file was executed during code generation. The listing, name.log (where name is the filename of the TLC file being analyzed), is placed in your build folder.

Note

A log file for every .tlc file invoked or included is generated in the build folder. Focus on timesN.log.

Open the Model and Generate Code

  1. In the MATLAB® Command Window, create a MEX-file for the S-function.

    mex timesN.c

    This avoids picking up the version shipped with your Simulink® software.

  2. Open the model simple_log.

  3. In the Code Generation pane of the Configuration Parameters dialog box, check Generate code only.

  4. In the Code Generation > Debug pane of the Configuration Parameters dialog box, select Start TLC coverage when generating code. (Do not select Start TLC debugger when generating code. Invoking the debugger is unnecessary.) Click Apply.

  5. Press Ctrl+B. The usual messages appear in the MATLAB Command Window, and a build folder (simple_log_grt_rtw) is created in your working folder.

  6. Enter the build folder. Find the file timesN.log, and copy it to your working folder, renaming it to timesN_ilp.log to prevent it from being overwritten.

  7. Open the log file timesN_ilp.log in your editor. It looks almost like timesN.tlc, except for a number followed by a colon at the beginning of each line. This number represents the number of times TLC executed the line in generating code. The code for Outputs() should look like this:

    0: %% Function: Outputs ========================================================
         0: %%
         1: %function Outputs(block, system) Output
         1:   %assign gain =SFcnParamSettings.myGain
         1:   /* %<Type> Block: %<Name> */
         0:   %%
         1:   /* Multiply input by %<gain> */
         1:   %assign rollVars = ["U", "Y"]
         1:   %roll idx = RollRegions, lcv = RollThreshold, block, "Roller", rollVars
         1:     %<LibBlockOutputSignal(0, "", lcv, idx)> = \
         1:     %<LibBlockInputSignal(0, "", lcv, idx)> * 1;
         0:   %endroll
         1: 
         0: %endfunction

    Notice that comments were not executed. TLC statements were reached, which means they output to the generated C code as many times as the number prefixed to those lines.

Changing code generation options can cause a latent issue in generated source code. Systematically changing options and observing the resulting differences in TLC coverage can facilitate the process of discovering faulty code.

Related Topics