Following chapter explains which events can be recorded with the BlueBox tools and how you can pinpoint interesting activities in an otherwise long trace session.

 

 

Events of interest

Trace tools can record various information generated by the MCU (program execution history, data accesses, instrumentation messages...). Please list the events of interest in the Profiler and Coverage Configuration page.

•Program execution - Trace records how the program was executed, to the granularity of single instructions. In case of conditional instructions it can most often even record how the instruction has executed (e.g. if the instruction condition evaluated to true or false). Program execution trace is instrumental in finding bugs in real-time execution, measuring code performance and in code coverage.

•Data access - Trace records accesses to memory (typically write accesses) and provides the address and the value which was stored to it. Data trace is typically used for data acquisition and OS event profiling.

•Instrumentation messages - Found on some on-chip trace architectures, the application can use special op-codes or writes to dedicated register(s), to generate these trace messages. This can reduce the amount of trace data considerably, and is usually the only trace available on low-end on-chip trace implementations.

•Other CPU activities - Apart from the above activities, the MCU might implement some advanced trigger functionality, which will generate a watchpoint message when a certain complex condition is met, some CPUs can signal entry and wake up from low power mode state... These features depend on the MCU architecture,

•Auxiliary events - Next to the trace stream originating from the CPU, a debugger can provide auxiliary inputs which can be traced alongside CPU. The advantage here is that events inside the CPU can be well correlated to events outside the CPU. The auxiliary inputs are typically digital, but analog signals or network protocol messages can be traced too.

•Time - One of the most important parts of the trace is a real-time timestamp assigned to every event as it is recorded. This can be either generated by the CPU (particularly when recording to an on-chip trace buffer), or by iSYSTEM tools when the trace messages generated by the trace port is recorded. Without a timestamp mechanism, real-time analysis and performance measurement is not possible.

 

 

What to record and when

Qualifier

Modern CPUs run at high frequencies and can therefore generate a lot of trace information. Despite trace stream compression on modern on-chip trace architectures, well over 100MB/s of data can be generated for a single-core running at 100MHz. A faster SoC with multiple cores will generate yet more data. This poses a problem when recording trace to an on-chip trace buffer (where available memory is extremely limited) or even when using a trace port which might not be able to handle such bandwidth. Without any filtering mechanism, the trace session would inevitably be limited in time, and the high-level analysis would take a lot of time (when Analyzer needs to process longer trace sessions).

To reduce the trace data bandwidth architectures implement a qualifier condition, which defines what trace data is recorded and what gets discarded. The qualifier can be used to record e.g.:

- only program flow (data trace would require higher bandwidth)

- only certain function execution (if you need to record longer sessions in an on-chip trace buffer)

- data writes to a certain address range (as recording all data accesses generates too much trace traffic, because the compression algorithms are not as effective)

- data writes to a particular variable with a particular value range

 

 

 

Trigger

By default, iSYSTEM tools will trigger immediately and start recording all the trace data generated by the MCU as soon as the trace session is started. Once the trace buffer is full, the recording will stop.

This is not desired when the activity of interest occurs infrequently - it could happen that the recording will already stop by the time the relevant part of the application is executed.

 

Instead, iSYSTEM tools can wait for the CPU to generate a trigger signal, which indicates that relevant content will follow. The trigger can be generated by various means, most commonly as a special signal which is routed through the debug connector. The trigger can be caused by various events, most commonly:

- execution of a certain instruction (e.g. entry to a function)

- data write to a specific address (e.g. task entry)

 

Until the trigger signal is received, recorder will keep overwriting the old trace data in the trace buffer.

Please refer to Recorder Configuration chapter to learn about different possibilities for trigger configuration.