The CYGPKG_SYSTEMVIEW package also provides for generation of records for some other system events.

The following options are enabled by default, but can be disabled to reduce the instrumentation capture load if overflows are encountered.

The following image is a screenshot from the SystemView “System” event window highlighting the basic thread and ISR information recorded. It shows a thread named “SimpleTest” being woken, executing for 2.704ms before sleeping and the idle thread executing again.

Figure 226.1. Example from application with SEGGER_SYSVIEW_Mark() use

Aside: The above example also highlights the use of an application generated SystemView “marker”. The events #455 and #456 show the application marked block with the name tloop took 26.822us for the 11th execution of the code covered by the marker.

If the eCos Kernel instrumentation (CYGPKG_KERNEL_INSTRUMENT) feature is enabled along with the CYGBLD_SYSTEMVIEW_KERNEL_INSTRUMENT option then CYGPKG_SYSTEMVIEW provides a wrapper header (CYGBLD_KERNEL_INSTRUMENT_WRAPPER_H) to replace the Kernel package implementation with code to generate SystemView events.

	Note
	In this case the normal Kernel instrumentation options CYGPKG_KERNEL_INSTRUMENT_TIMESTAMPS and CYGPKG_KERNEL_INSTRUMENT_BUFFER are ignored, since the CYGPKG_SYSTEMVIEW support is used to record instrumentation. However the CYGPKG_KERNEL_INSTRUMENT_BUFFER option should be disabled.

The specific CYGPKG_KERNEL instrumentation types can then be manually enabled/disabled as required for the SystemView analysis being performed. e.g. CYGPKG_KERNEL_SCHED instrumenting low-level scheduler events can be disabled to save on bandwith; if tracking thread and synchronisation object events is sufficient for the analysis.

Similarly, most packages that make use of Kernel instrumentation do so as eCos configuration conditionals.

These low-level kernel instrumentation events can provide very low-level detail of the inner processing of eCos, and the application use of kernel scheduling objects, but it can generate vast amounts of trace data.

The following image is a screenshot from the SystemView “System” event window which highlights the level of detail available when Kernel instrumentation is enabled. Entry #60098 is the start of a mutex lock operation, with the lock call completing after 215.839us as shown by entry #60102.

Figure 226.2. Example from application with Kernel instrumentation enabled

The above screenshot is from an execution of the CYGPKG_KERNEL test mutex3, where the created thread has not been given a name, hence the empty thread name being displayed as <<NULL>>. This example was captured on the eCos stm32f746g_disco target platform (executing at 168MHz and using the UART HAL Recorder with a baud rate of 2MHz).

Warning

When using eCos itself to support the CYGOPT_SYSTEMVIEW_RECORDER channel this means that the act of providing support to SystemView will itself add more low-level events, further compounded if the USB CDC-ACM or network stacks are used for the Recorder support, since they will have their own threads and kernel synchronisation objects that will further increase the load. It is more likely that RTT overflows will occur with such a configuration. It is recommended to use, when available for the selected target, the lower-level CYGOPT_SYSTEMVIEW_RECORDER_HAL option when using Kernel instrumentation if the use of H/W RTT access is not available.

In extremis, the Infrastructure (CYGPKG_INFRA) package option CYGDBG_USE_TRACING can be enabled in conjunction with selecting CYGDBG_INFRA_DEBUG_TRACE_ASSERT_SYSTEMVIEW as the trace destination output module.

This feature will provide a trace of the execution of suitably annotated functions. This will mostly be similar in nature to the information that can be obtained from enabling (the lighter weight) Kernel instrumentation, but can be useful for developers wishing to understand the location of the source for the code being executed.

Note

The use of this feature is not normally recommended, but can be useful for some investigation/analysis cases. The recording of long strings via the SystemView Log mechanism will affect the performance of the application under test, due to the formatting and transfer overhead of long strings. If detailed eCos operation is required then normally Kernel instrumentation would be sufficient, and whilst it can also generate significant amounts of trace data it will be less than the overhead of the printf-style output from the Infrastructure Tracing support.

The following image highlights the style of Tracing output generated.

The Detail entries are prefixed with the <source-filename>[source-line#]<function-name> fields, which are then followed by the Tracing specific message text.

Figure 226.3. Example from application using INFRA trace

The example above was captured on the eCos stm32f746g_disco target platform (executing at 168MHz and using the UART HAL Recorder with a baud rate of 2MHz).