Chapter 94. Debug and Test

Table of Contents



If the target platform resources allow, then the first step in debugging should be to enable ASSERTs. The inclusion of assert checking will increase the code footprint and lower the performance, but does allow the code to catch internal errors from unexpected data values. e.g. when the application/client is not able to guarantee the validity of data passed into the CCB code.

The CCB asserts are controlled via the standard eCos Infrastructure CYGPKG_INFRA package CYGDBG_USE_ASSERTS option. If enabled then run-time assertion checks are performed by the CCB package.

If assertions are enabled and a debugger is being used, it is normally worthwhile setting a breakpoint at start-up on the cyg_assert_fail symbol. The debugger will then stop prior to entering the default busy-loop assert processing.

Diagnostic Output

In conjuction with the CYGDBG_COHERENT_CCB_DEBUG CDL configuration setting and its sub-options, the header-file src/ccb_diag.h implements the CCB I/O package specific debug control.

When CYGDBG_COHERENT_CCB_DEBUG is enabled a set of individually selectable sub-systems are available to control the diagnostic output generated.

However, when developing or debugging the CCB implementation it may be simpler (with less build side-effects) to control the debugging output via direct uncommenting of the necessary manifests at the head of the src/ccb_diag.h source file, than re-configuring the complete eCos configuration via the CDL. This approach will limit rebuilding to just the CCB package.

Note: When enabled, some diagnostic output may adversely affect the operation of the CCB support as seen by 3rd-party code. For example, “slow” serial diagnostic output of the packet parsing and response generation could mean that a significant amount of time passes, such that the CCB support no longer adheres to the timeout limits imposed by external code.

Documentation license for this page: eCosPro License