Overview

After the sources are compiled, the resulting VCWM executable must be integrated with the target platform’s runtime environment. Due to the multitude of hardware platforms and custom runtime environments a first time VCWM integration will likely require some debugging.

Luckily the VCWM executable has two built-in troubleshooting mechanisms to help quickly pin-point and resolve integration issues.

The first troubleshooting mechanism is the configurable real-time trace interface. The VCWM’s configuration file’s trace options https://sitesage.atlassian.net/wiki/spaces/OPK/pages/297697310/VCWM+Configuration+File#Trace-Optionscause detailed trace output to be generated. If uncertain which trace options to enable they can all be set to true.

The second troubleshooting mechanism is the assertion interface. When an unrecoverable error occurs the VCWM process will output an assertion message that includes the source file and line number where the error occurred. The latest development version also reports the last errno string and code, which is helpful to debug file and permissions issues. When running the VCWM as a daemon the assertion string is written to a file named vcwmAssert.log in the Temporary Directory specified in the configuration file https://sitesage.atlassian.net/wiki/spaces/OPK/pages/297697310/VCWM+Configuration+File#Temporary-Directory.

Finally, if using both assertion and trace output is insufficient then the VCWM process can be debugged using GDB. The default VCWM build script enables debugging so that it is easy to inspect the VCWM process state.

Steps

1. Ensure that all the implementation requirements are met: Embedded Linux Implementation RequirementsUNDEFINED

2. Enable all trace in the VCWM configuration file: https://sitesage.atlassian.net/wiki/spaces/OPK/pages/297697310/VCWM+Configuration+File#Trace-Options

3. Run the VCWM executable in the foreground from a terminal on the target, eg. ./vcwm vcwm.json.

4. If an assertion occurs the VCWM process will exit, and the source file and error code indicated by the assertion text can be examined. Many common problems can be easily understood and corrected through inspection of the source in combination with an error code.

5. If the VCWM process runs but data is still not being received by the OKC then the trace output must be analyzed.

   1. Is the VCWM process repeating the same sequence of steps?

   2. If yes, are any recoverable errors being reported in the trace? For example, are there TLS handshake errors that might indicate an SSL certificate problem?

   3. If no, what tasks is the VCWM process executing?

   4. Does the OKE simulator communicate successfully with the VCWM process?

   5. If yes, what network status does the VCWM process report to the OKE?

6. If the assertion and trace output still does not help identify the problem the VCWM executable can be debugged using GDB.

   1. Run gdb from a terminal window: gdb ./vcwm

   2. For assertions set a breakpoint for function named SSFPortAssert(): b SSFPortAssert

   3. For trace debugging set a breakpoint near where the problem is occurring.

   4. Run the VCWM process in the debugger: r vcwm.json

   5. When the breakpoint is hit inspect the backtrace and switch frames to the function where the problem is occurring. Inspect the state of the system to determine what might be causing the problem. See GDB (Step by Step Introduction) - GeeksforGeeks and other online resources for how to use GDB.