Debug RobustOS SDK Applications With Logs and GDB Tools

Debug a RobustOS SDK application

Start with application logs to identify the failed operation. Use TFTP for a short executable-test cycle on a development device, or gdbserver when you need breakpoints and variable inspection. Each method checks a different stage of application development.

Applies to: Applications built with the matching RobustOS SDK for a designated development device. Root-shell access and debugger availability depend on device firmware and Robustel authorization. Build targets vary by model; see the RobustOS SDK starting page.

Start with evidence from the failing stage

Keep the build log, SDK image and target, source revision, package checksum and device firmware together. Record whether the failure occurred during compilation, packaging, installation, startup or a later service interaction. Fixing a compile error does not establish that the device accepted or ran the package.

Start with the device's Web interface at System > Debug. Match messages to the current attempt using its time window. The first application writes hello world at debug level and then exits; a stopped process after that message is expected.

On a device where root-shell access is already authorized, the system log is available at /var/log/messages. Debug-level filtering and application execution are separate checks: an absent message may mean that it was not displayed or that the program never reached the log call.

Use SDK logging functions such as log_debug(), log_info() and log_error(). Refer to the logging API reference when adding application logs. Include enough context to identify the failed operation, while excluding passwords, tokens and private payloads from logs you share.

Obtain device-shell access when the task needs it

You can build a package without logging into the device as root. Root-shell access is disabled by default and requires a device-specific license. Device-shell debugging uses a separate authorization process:

  1. Provide the device serial number to your Robustel contact through the agreed support channel.
  2. Complete the required nondisclosure agreement (NDA) with that contact and obtain the license file issued for the device.
  3. Import the license through the device Web interface using the firmware's license/update workflow.
  4. After activation, configure the root account password in the Web interface's user-management workflow.
  5. Use the authorized SSH or serial-shell access for development.

Do not assume that a license for another device applies, or that enabling Developer Mode grants root access. These are distinct prerequisites. Keep passwords and license files out of source repositories and support-log bundles.

Important: Use only the access method and credentials authorized for your device. Keep root-shell and debugger access on the trusted development network; do not expose either service to an untrusted network.

Transfer a development executable when you already have shell access

For an approved development network, TFTP provides a short iteration path for copying a rebuilt executable. It does not replace package installation or signature acceptance testing.

Find the target executable under the current SDK build directory. Confirm that it belongs to the device target and current source revision, then make it available on your development TFTP server. The following device-shell example downloads a file named example from an example server address:

tftp -g 192.168.0.10 -r example -l /usr/bin/example
chmod 755 /usr/bin/example
/usr/bin/example

Replace the address and filenames for your development environment. Run the lines in order and check that each succeeds before continuing; if the transfer fails, do not execute an older file already at the destination. The destination is written on the device: check for an existing executable before using that path. Use this procedure on the designated development device and network. A successful direct execution tests that binary; separately verify the packaged installation and lifecycle script.

Build and configure gdbserver

Inside the SDK container, from /root/ROS-SDK with the device target already selected, build the debugger package:

make package/gdbserver/install

Find and export the RPK produced by this build. Install it through the device's authorized application-installation workflow, including signing or approved development requirements.

In the debugger settings on the device, configure:

Setting Purpose
Enable Run the debugger service for this debugging session
Port The listening port that the development-side GDB will connect to
App The executable filename to debug
Attach Attach to an existing process when enabled; otherwise start a process for debugging

Example debugger settings showing Enable, Port, Attach and App

The example uses port 8888 and application e2c_s_modbus. Use the values for your session; the screenshot does not identify a universal menu path or application name. With authorized shell access, use ps to inspect whether gdbserver is running. Restrict debugging to the intended development network, and turn off the debugging service when you finish.

Build matching debug symbols and connect

The debugger needs the executable containing symbols for the code running on the device. For this SDK build workflow, add RGDB_DEBUG=1. For example, inside the SDK container:

make package/e2c_s_modbus/install RGDB_DEBUG=1

This is an example package name. Use an application that exists in your SDK tree. Preserve the unstripped executable from the matching build; the installed device copy need not carry debug symbols, but its code must match the executable loaded by GDB.

Export and install the application package from that same build on the development device through the authorized installation workflow. For a deliberate direct-executable debugging session, transfer the matching target executable instead. Then make sure gdbserver starts that executable, or, when Attach is enabled, attaches to a process running that build. Updating the file alone does not establish that an already running process has changed.

Use the GDB executable from the target cross-toolchain, in the environment where that toolchain can run. Its path follows this pattern:

staging_dir/target-<PLATFORM>/<GNU_TARGET_NAME>/bin/<GNU_TARGET_NAME>-gdb

Examples of target-specific paths are:

staging_dir/target-r3000/arm-sam9x25-linux-gnueabi/bin/arm-sam9x25-linux-gnueabi-gdb
staging_dir/target-r2110/mipsel-74kc-linux-gnu/bin/mipsel-74kc-linux-gnu-gdb
staging_dir/target-r1510/mips-24k-linux-gnu/bin/mips-24k-linux-gnu-gdb

Inspect your selected SDK for its actual path. Do not choose one only because a model name resembles your device. The SDK environment must also have a network path to the debugger port on the development device.

For the R2110 e2c_s_modbus example, start GDB inside the SDK container from /root/ROS-SDK. The backslash below continues a single shell command:

./staging_dir/target-r2110/mipsel-74kc-linux-gnu/bin/mipsel-74kc-linux-gnu-gdb \
  build_dir/target-r2110/edge2cloud/e2c_s_modbus/e2c_s_modbus

At the GDB prompt, use the address and port configured for the device:

target remote 192.168.0.1:8888
break modbus_plc.c:873
continue
print recv_bytes

The filename, line number and variable belong to that example. For your application, select a source line that exists in the matching build and inspect a variable in scope after the breakpoint is reached.

Check each result in order: GDB loads the symbols, the remote connection succeeds, the breakpoint resolves, execution stops there and the variable is available. If a breakpoint does not resolve, first compare source and executable identity. If the connection fails, check the device address, port, service process and development-network reachability before changing application code.

Use desktop tests for portable logic

Develop and test hardware-independent logic on a desktop when useful. Then rebuild with the target SDK and test on the device. Desktop results do not cover target-specific type sizes, library behavior, file paths, services or hardware. Retain the target-build and device checks before release.

Related tasks