Chapter 107. Debug and Test
Table of Contents
If the target platform resources allow then the first step in
debugging should be to enable
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 MODBUS
The MODBUS asserts are controlled via the standard eCos
CYGDBG_USE_ASSERTS option. If enabled then
run-time assertion checks are performed by the MODBUS package.
If assertions are enabled, and a debugger is being used it is normally
worthwhile setting a breakpoint at start-up on
cyg_assert_fail symbol, so that the debugger
will stop prior to entering the default busy-loop assert processing.
107.1.2. Diagnostic Output
In conjuction with the
configuration setting and sub-options, the
implements the MODBUS specific debug control.
CYGDBG_MODBUS_DEBUG is enabled a set of
individually selectable sub-systems are available to control the
diagnostic output generated.
However, when developing or debugging the MODBUS 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
file, than re-configuring the complete eCos configuration via the
CDL. That way only the MODBUS package will be re-built.
Some diagnostic output if enabled may adversely affect the operation of the MODBUS 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 MODBUS support no longer adheres to the timeout limits imposed by external code.
The configuration option
defines a set of tests that are built.
By default the package will only build the deterministic, automatic,
tests. However, the
CYGPKG_MODBUS_TESTS_MANUAL can be defined to
build extra tests that may required manual user-intervention, or are
more realistic real-world example applications.
The modbus_ut test application performs some
unit-testing of the ModbusTCP server implementation. The test assumes
specific features of the
backend implementation to perform a variety of fixed tests.
Since the backend handler funtions can NEVER block the test code will explicitly test pending responses to simulate application situations where hardware responses may take arbitrary periods of time, and hence are passed to other user-application threads for processing.
When configured against the lwIP network stack the unit-testing relies
on lwIP being configured
The modbus_server is only built
CYGPKG_MODBUS_TESTS_MANUAL is configured. It
tests/backend_dummy.c as the backend for
a simple example server.
The application just runs for a fixed period of time before terminating, and can be used with external ModbusTCP clients.
|2019-09-17||eCosPro Non-Commercial Public License|