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 driver 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 driver 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.

The STM32 CCB driver provides the ability for some diagnostic output to be manually enabled by editing the src/stm32_ccb.c directly. However, in normal application development the low-level diagnostics for this driver should not be required.

	Note
	The diagnostics within this package are to aid driver development and debug, and will 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.

Similar to the diagnostic output, the source can be edited to manually enable support for software driven signals that can be sampled by a suitable Logic State Analyser (LSA) setup. This can be used to track time critical events.

	Warning
	Any STM32 I/O pins chosen for LSA signalling should be carefully chosen to avoid adverse operation of the target platform in use.