Interacting with the target

For development purposes, embedded platforms are usually accessed through a JTAG or an SWD interface. Through these communication channels, it is possible to upload the software onto the flash of the target, and access the on-chip debug functionalities. There are several self-contained JTAG/SWD adapters on the market that can be controlled through USB from the host, while some development boards are equipped with an extra chip controlling the JTAG channel, that connects to the host through USB.

A powerful generic open source tool to access JTAG/SWD functionalities on the target is the Open On-Chip Debugger (OpenOCD). Once properly configured, it creates local sockets that can be used as a command console and for the interaction with the debugger frontend. Some development boards are distributed with additional interfaces to communicate with the core CPU. For example, STMicroelectronics prototyping boards for Cortex-M are rarely shipped without a chip technology called ST-Link, which allows direct access to debug and flash manipulation functionalities. Thanks to its flexible backend, OpenOCD can communicate with these devices using different transport types and physical interfaces, including ST-Link and other protocols. Several different boards are supported and the configuration files can be found by OpenOCD.

When started, OpenOCD opens two local TCP server sockets, on preconfigured ports, providing the communication services with the target platform. One socket provides an interactive command console that can be accessed through Telnet, while the other is a GDB server, used for remote debugging, as described in the next section.

In order to configure OpenOCD for the STM32F746-Discovery target, we can use the following openocd.cfg configuration file:

telnet_port 4444
gdb_port 3333
source [find board/stm32f7discovery.cfg]

The board-specific configuration file, imported from openocd.cfg through the source directive, instructs OpenOCD to use the ST-Link interface to communicate with the target, and sets all the CPU-specific options.

The two ports specified in the main configuration file, using the telnet_port and gdb_port directives, instruct OpenOCD to open two listening TCP sockets.

The first socket, often referred to as the monitor console, can be accessed connecting to the local 4444 TCP port, using a Telnet client from the command line:

$ telnet localhost 4444
Open On-Chip Debugger
>

The sequence of OpenOCD directives to initialize, erase the flash, and transfer the image starts with:

> init
> halt
> flash probe 0

The execution is stopped at the beginning of the software image. After the probe command, the flash is initialized, and OpenOCD will print out some information, including the address mapped to write on the flash. The following information shows up with the STM32F746:

device id = 0x10016449
flash size = 1024kbytes
flash "stm32f2x" found at 0x08000000

The geometry of the flash can be retrieved using the command:

> flash info 0

Which on the STM32F746 shows:

#0 : stm32f2x at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0
# 0: 0x00000000 (0x8000 32kB) not protected
# 1: 0x00008000 (0x8000 32kB) not protected
# 2: 0x00010000 (0x8000 32kB) not protected
# 3: 0x00018000 (0x8000 32kB) not protected
# 4: 0x00020000 (0x20000 128kB) not protected
# 5: 0x00040000 (0x40000 256kB) not protected
# 6: 0x00080000 (0x40000 256kB) not protected
# 7: 0x000c0000 (0x40000 256kB) not protected
STM32F7[4|5]x - Rev: Z

This flash contains eight sectors. If the OpenOCD target supports it, the flash can be completely erased issuing the following command from the console:

> flash erase_sector 0 0 7

Once the flash memory is erased, we can upload a software image to it, linked and converted to raw binary format, using the flash write_image directive. As the raw binary format does not contain any information about its destination address in the mapped area, the starting address in the flash must be provided as the last argument, as follows:

> flash write_image /path/to/image.bin 0x08000000

These directives can be appended to the openocd.cfg file, or to different configuration files, in order to automate all the steps needed for a specific action, such as erasing the flash and uploading an updated image.

Some hardware manufacturers offer their own set of tools to interact with the devices. STMicroelectronics devices can be programmed using the ST-Link utilities, an open source project that includes a flash tool (st-flash) and a GDB server counterpart (st-util). Some platforms have built-in bootloaders that accept alternative formats or binary transfer procedures. A common example is Device Firmware Upgrade (DFU), which is a mechanism to deploy firmware on targets through USB. The reference implementation on the host side is dfu-util, which is a free software tool.

Each tool, either generic or specific, tends to meet the same goal of communicating with the device and providing an interface for debugging the code, although often exposing a different interface toward the development tools.