- 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 CCB
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
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.
Any STM32 I/O pins chosen for LSA signalling should be carefully chosen to avoid adverse operation of the target platform in use.