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 MODBUS code.

The MODBUS 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 MODBUS 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, so that the debugger will stop prior to entering the default busy-loop assert processing.

In conjuction with the CYGDBG_MODBUS_DEBUG CDL configuration setting and sub-options, the header-file src/modbus_diag.h implements the MODBUS specific debug control.

When 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 of the src/modbus_diag.h source file, than re-configuring the complete eCos configuration via the CDL. That way only the MODBUS package will be re-built.

	Note
	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 modbus_ut test application performs some unit-testing of the ModbusTCP server implementation. The test assumes specific features of the tests/backend_dummy.c 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.

	Note
	When configured against the lwIP network stack the unit-testing relies on lwIP being configured with CYGFUN_LWIP_NETIF_LOOPBACK. This is required to allow the test code to connect to the ModbusTCP server running on the same network interface.

The modbus_server is only built when CYGPKG_MODBUS_TESTS_MANUAL is configured. It uses the 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.