Internet Explorer no es un explorador compatible con TI.com. Para disfrutar de una mejor experiencia, utilice otro navegador.

VIDEO SERIES

Serie Precision labs: Programación y software

En esta serie aprenderá los conceptos básicos de la programación y el software.

Video Player is loading.
Current Time 0:00
Duration 0:00
Loaded: 0%
Stream Type LIVE
Remaining Time 0:00
 
1x
  • Chapters
  • descriptions off, selected
  • subtitles off, selected

      Presenter(s)

      [AUDIO LOGO]

      Hello. I'm Matthew Pate. And today, I will give a brief overview of debugging with Code Composer Studio on TI embedded processors and microcontrollers.

      In this video, we will go through various features helpful in debugging applications using Code Composer Studio. We will cover the following topics in this video, how to debug applications using TI Code Composer Studio or similarly integrated development environments or IDEs, explain how to launch the debug session, what happens when debug session is launched, explain various debugging tools like breakpoint variables, CPU registers, and memory view, and finally, the graphing tools.

      The first action is to get co-composer studio installed on your host machine and then connect it to the debug target of your choice. There are two options to connect CCS to your target, depending on the hardware available. Some targets, such as the LaunchPad, have the debug probe on the PCB and can be connected in power through a single USB connection illustrated to the right. The other option is to power the target externally and connect through the external debug probe, like the XTS 110 or XTS 200, using a USB cable.

      Launching the debug session can be done with one click. Simply press the bug icon on the CCS toolbar to launch the debug session. This will do multiple things automatically. It will open multiple panes useful for debugging.

      CCS uses the target configuration file to connect to the target. GEL script is used for hardware initialization. The GEL script is automatically imported as part of the target configuration file that is in use.

      After debug launch, the IDE opens multiple windows useful for debugging an application. The source code view shows the program halted at the beginning of the main function. The variables, expressions, and register views are also open by default. The debug view lists all the cores on the device and the call stack for each core. In the example to the right, we have a device with four cores visible to the debugger. Disassembly and memory view may also be visible if enabled. I will discuss this more in detail in a later slide.

      These are the basic commands you will use during a debugging session. Resume, starts code execution if the device is halted. Suspend, halts code execution if the target is running. Terminate, disconnects the target and terminates the debug session. Step into, executes a single source line, stepping into subroutines or function. Step over, running the code one line at a time, stepping over subroutines or functions. And step return, run all lines until the program counter reaches a caller of the function.

      Breakpoints stop code execution and allow users to view the values of variables and expressions. How to set the breakpoint. There are two main methods for setting a breakpoint. Double click the blue shaded area in the code next to the line number, or it can also be added by right clicking on the dot C file and selecting breakpoint.

      There are two types of breakpoints. The software breakpoint, it can only be set in memory regions with write access, which is RAM, and no theoretical limit to the number of software breakpoints. The other type are hardware breakpoints. These are dependent on the device and implemented internally by the target hardware. Debugger writes the address to a register on the device and sets a flag to enable these hardware breakpoints.

      These can be set to any memory type, RAM, Flash, or ROM. There is also a subset of the hardware breakpoint which is the hardware watch point. This is a special category of a hardware breakpoint triggered by memory accesses instead of instruction acquisitions.

      Let's now take a look at some different aspects of the debug system. First, we will talk about variables. Local variables can be viewed in the variables window. Variables whose values have changed are highlighted in a yellow background. The value of a variable may be modified by clicking its value column and entering a new value.

      In devices that have separate program and data pages, this is suffixed by the at symbol followed by the page name, program data or IO. If the variable is located to a register, this field will show the word register followed by its register name. For formatting of a variable, right click on the given variable and select desired format from the context menu.

      Next, let's take a look at the watch expression variables. These are variables that are local, global, or static, a C valid expression, and registers that can be monitored. Expressions that contain more than one element, such as arrays, structures, or pointers, are displayed with either a plus sign or a minus sign immediately preceding the expression name. Expressions whose values have changed since the last time they were seen are highlighted in a yellow background. For formatting of the expression, right click on a given variable and select the desired format from the context menu.

      Now, looking more into the register and memory views, first is the register view where we can view and edit the CPU core registers. Then is the memory browser pane. This view is not open by default but can be opened in the CCS menu by selecting View, then Memory Browser. This shows the contents of the target memory starting at the specified address. Data can be viewed, written, or saved in different formats, and the format can be selected from a dropdown list.

      Finally is the disassembly view. The disassembly view translates machine language into assembly language instructions. This displays the disassembled instructions and symbolic information needed for debugging. This can be viewed by going into the CCS menu View then Disassembly.

      The last topic we will cover are the graph tools. An advanced graph and image visualization tool is available in Code Composer using the CCS menu Tools then Graph. This will display the data in an X-Y plot format.

      The data formatting and plotting is entirely done by the host, but using the data present on the target device's memory. The graph tool does not modify the data on the target memory, but only fetches it via the debug probe connection to update its view. Use manual Halt or Breakpoint to update the graph or enable the option Continuous Update in the Graph toolbar.

      Thanks for viewing today's presentation on debug applications. To find more microcontroller and processor technical resources and search products, please visit the links shown here.

      View series

      Serie Precision labs: Programación y software