If the target platform resources allow 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 do 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 CDC-EEM layer.
The CDC-EEM transport 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 CDC-EEM driver.
If assertions are enabled, and a debugger is being used it is normally
worth-while setting a breakpoint on
cyg_assert_fail symbol so that the debugger
will stop prior to entering the default busy-loop processing.
In conjuction with the CYGDBG_CDCEEM_DIAGNOSTICS CDL configuration setting, the source-file src/cdceem.c implements the CDC-EEM specific diagnostics control.
When CYGDBG_CDCEEM_DIAGNOSTICS is enabled a set of individually selectable sub-systems are available to control the diagnostic output generated.
However, when developing or debugging the CDC-EEM driver implementation it may be simpler (with less build side-effects) to control the debugging output via uncommenting the necessary manifests at the head of the src/cdceem.c source file than re-configuring the complete eCos configuration via the CDL. That way only the CDC-EEM package will be re-built.
Note: Some diagnostic output if enabled may adversely affect the operation of the CDC-EEM driver 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 CDC-EEM driver no longer adheres to the timings required by the USB host driver.