Debuggers are obviously created to help developers look inside the application as it executes in the target system. The whole point is to create an interactive, or semi-interactive, execution environment where the developer largely control the execution. But what if you want to completely automate the debugger? There are many use-cases where that is convenient.
In fact, this is possible using Atollic TrueSTUDIO. You can write script files that completely control the execution of the debugger. In effect, you can completely automate certain repetitive debugger tasks.
There are several ways of doing this; and I will cover one of them in this blog post. Today, I will explain how you can write a script file with a sequence of GDB debugger commands, that you can run over and over again automatically. These script files can even include function definitions and function calls, iterations and if...then logic.
The GDB script files supports some 800 commands, including:
- Conditional statements
- Function definitions and function calls
- Reading and writing variables
- Reading and writing to target addresses
- Printing formatted dynamic data to output log files
- Connecting scripts to breakpoint hit events
Here is a basic example:
1. Start the GDB-server
This example uses the ST-Link GDB-server, but it works in a similar way with Segger J-Link as well. From the Micosoft Windows command line console, type:
> cd "Program Files (x86)\Atollic\TrueSTUDIO for ARM 7.1.0\Servers\ST-LINK_gdbserver\"
The GDB-server should now be started and wait for the GDB debugger to connect.
2. Create a debugger automation script file
Using a text editor, create a debugger script file (in this example, called "scriptfile ") containing the gdb debugger commands you want to automate:
# connect to the gdbserver
target remote localhost:61234
# turn off pagination in GDB
set pagination off
# Set flash parallelism mode to 32, 16, or 8 bit when using STM32 F2/F4 microcontrollers
# 2=32 bit, 1=16 bit and 0=8 bit parallelism mode
monitor flash set_parallelism_mode 2
# Set character encoding
set host-charset CP1252
set target-charset CP1252
# Load the program executable
# Reset the chip to get to a known state. Remove "monitor reset" command
# if the code is not located at default address and does not run by reset.
# Enable Debug connection in low power modes (DBGMCU->CR)
set 0xE0042004 = (0xE0042004) | 0x7
# Some simple automation scripting - define a function:
if i % 2 == 1
# Set a breakpoint at main(). Whenever the breakpoint is hit, the function is called automatially
# Run to the breakpoint.
Save the script file and use it as explained in section 3 below. Another cool trick is to have the debugger script auto-generate a custom-formatted log file that you can use for various purposes. Using this method, you can print static text, variable values or the value of CPU registers or memory locations using any formating you like.
You can do that with script code similar to this:
set logging file myoutputfile.txt
set logging on
printf “UNIT TEST #%d\n\nPass: %d\nFail: %d\nCould not run: %d\n”, TestNr, NrOfPassed, NrOfFailed, NrOfErrors
This will generate output similar to this in the log file myoutputfile.txt:
UNIT TEST #215:
Could not run: 0
Using this method, you can create a system that automatically download and run the application under script control in the target system, for example batch-running of test code.
3. Launch the debug session
With the gdb debugger script created, for exampe using the example above, we now only need to start using it. Start the GDB debugger from the Microsoft Windows command line console (or a batch file for further automation on a higher abstraction level), and feed the script file and the application binary into it:
> "c:\Program Files (x86)\Atollic\TrueSTUDIO for ARM 7.1.0\ARMTools\bin\arm-atollic-eabi-gdb.exe" -x scriptfile mybinary.elf
The debugger will now start and perform the automated tasks you have defined in the script file.