Chapter 101. Debug and Test
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
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.
101.1.2. Diagnostic Output
The STM32 CCB driver provides the ability for some diagnostic output
to be manually enabled by editing
src/stm32_ccb.c directly. However, in
normal application development the low-level diagnostics for this
driver should not be required.
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.
|2018-07-27||eCosPro Non-Commercial Public License|