(This is the first in an occasional series around the scripting in eclipse and CodeWarrior. Post a comment – let me know what you think!)

Writing code should be fun, and debugging it is just a necessity because I rarely get it right the first time. Eclipse with its GUI is a great thing, and so is a command line interface. Luckily the CodeWarrior eclipse engineers have added that kind of tool for the CodeWarrior debugger: the Debugger Shell as command line debugger using the TCL scripting language. This gives me a powerful way to deal with the embedded target board: from basic access to memory, to stepping and controlling the execution up to programming the flash memory.

The Debugger Shell is available from the Window > Show View menu:

Show View: Debugger Shell

A good command to use is help. This lists the built-in commands:

Help Command

It has an auto-completion feature as well: start typing a command and then press TAB: this will show all matching commands with the syntax:

Quick Help

Most commands have as well a short version: so I can type help or just h. That saves me some writing time. Additionally I can use the cursor keys to go up and down my command history.

If I default launch configuration, I simply use the debug command:

%>debug
Launching {1}: 0% complete 
: 0% complete 
: 7% complete 
Launching application: 7% complete 
Creating debug session: 7% complete 
Launching executable: 7% complete 
Preparing executable: 7% complete 
Loading symbolic information: 7% complete 
Finished loading symbolic information: 7% complete 
Preparing executable: 7% complete 
thread break: Stopped, 0x0, 0x0, cpu68K, test_UIWidgets.elf (state, tid, pid, cpu, target) 
thread set: Stopped, 0x0, 0x0, cpu68K, test_UIWidgets.elf (state, tid, pid, cpu, target) 
Downloading 14468 bytes...: 7% complete 
Download using 3rd party component...: 7% complete 
Download using 3rd party component...: 100% complete 
thread break: Stopped, 0x0, 0x0, cpu68K, test_UIWidgets.elf (state, tid, pid, cpu, target)

But how to know which one is the default launch configuration? There is the launch command which tells this:

%>launch
 *>0 - test_UIWidgets_MCF51JM128_Internal_Flash_PnE U-MultiLink [CodeWarrior Download] 
   1 - TWR-LCD JM128 Bootloader PnE [CodeWarrior Download] 
   2 - Attach FSLBOT MCF52259_Internal_Flash [CodeWarrior Attach] 
   3 - Tower MCF52259 HotSync [CodeWarrior Attach]

The line item with the star (*) denotes my current default launch configuration. Knowing the list of launches, I can use any index to debug a project:

%>debug 1

Or I can use the name:

%>debug "TWR-LCD JM128 Bootloader PnE"

Terminating or killing the debug session is simple using the kill command:

%>kill
thread exit: Stopped, 0x0, 0x0, cpu68K, TWR-LCDBootloader.elf (state, tid, pid, cpu, target)

Stepping is easy: step asm or stepi steps an assembly instruction:

%>step asm
%>stepi

There are as well stepping instruction to step over, step into or step out of a function:

%>step into
%>step over
%>step out

To set a breakpoint, I use the bp command. Using bp without argument will list my breakpoints as well.

%>bp main
  id  instance       address   type  enabled?  process  description 
  #5        #1  m:0x00002f86  -auto  ENABLED        $0  ProcessorExpert.c, line 53, main [TWR-LCDBootloader.elf]

To resume the application, I use the command go:

%>go

If it does not hit a breakpoint, I use stop to halt the target:

%>stop

To inspect my variables, I use the var command:

%>var fileStatus
$00         
%>var BL_flashErased
$01

And to inspect the memory, I use the mem command:

%>mem 0x00800874 16
    800874  $0000177A $00002F84 $00002F98 $00002C8A   z... ./.. ./.. .,..  
    800884  $00000000 $00002C9C $00000000 $65000C03   .... .,.. .... ...e  
    800894  $4A004D00 $31003200 $3800001E $45FF0000   .M.J .2.1 ...8 ...E  
    8008a4  $0200EB3C $904D5344 $4F53352E $30000220   <... DSM. .5SO  ..0

OK, that’s enough for now. This allows me to do all the basic debugging.

Next time I’m going to explore how I can script a debug session. I want to automate things. The goal is to use scripts for unit tests using the Debugger Shell.

Happy Shell Debugging