In this topic:
To efficiently capture and analyze CPU activity, BlueBox tools rely on access to detailed information about the CPU's operations.
The on-chip trace module plays a pivotal role in this process as it possesses the ability to observe all CPU activities. This module is equipped with its own trigger and qualifier logic, ensuring event capture. Moreover, it employs compression techniques to optimize bandwidth usage and subsequently minimize the number of pins required for trace data transmission. The timing information remains uncompressed, preserving its accuracy. Timestamps can either be generated by the CPU or the trace tool, though the latter option sacrifices some timing precision, marking the reception of trace messages rather than the exact execution time of individual instructions.
Once the compressed data package is prepared, it offers two avenues for further handling:
•Streaming through a Trace Port: Real-time transmission of trace data for immediate analysis or external monitoring.
•Storage in an On-Chip Trace Buffer: Internal storage of trace data for later retrieval and analysis.
BlueBox tools are adaptable to various CPU architectures, each featuring distinct On-Chip Trace (OCT) modules. To gain a deeper understanding of their capabilities and compatibility, please consult separate documentation tailored to specific OCT modules. This modularity ensures that trace features, encompassing program execution tracing, data access monitoring, instrumentation messages, and more, are tailored to the capabilities of the OCT module integrated into the CPU in use. This flexibility allows for precise and efficient CPU activity tracking across diverse platforms.
Trace Port is comprised of several dedicated CPU pins, through which the trace messages can be streamed. These signals are typically routed to the debug connector, through which the BlueBox tools communicate with the CPU and record the trace messages when they are being streamed. Once the trace message is recorded, BlueBox tools append a timestamp and therefore provide the timing information.
There are some inevitable drawbacks compared to the On-Chip Trace Buffer (OCTB):
Since the CPU activity is compressed and qualifier is employed, trace messages are not generated at a constant rate. While the trace port is sized to sustain an average bandwidth, at times the rate of generated messages will exceed it.
To compensate, the OCT module uses a message FIFO (typically 16-64 entries deep). Still, if the qualifier is set too widely, FIFO can get filled and subsequent OCT messages cannot be inserted.
Such situation can be handled in these manners:
•Trace is stopped, indicating FIFO overflow.
•Trace messages (usually the data trace) are suppressed until FIFO is freed to some level, then they resume, creating a gap.
•CPU is stalled until one FIFO entry is free.
FIFO overflows can be avoided by limiting the amount of information you wish to record or by increasing the trace port bandwidth (either by using a wider port or a higher trace clock).
Timestamp is generated by the BlueBox, when a trace message is received and stored in the buffer. However, message propagation delay from the observed event to the trace port output is not constant – because one message might stream immediately, but another would have to wait multiple cycles in the FIFO. While this reduces the time accuracy considerably, it is in practice less noticeable because:
•FIFO load is relatively constant - and usually low, if sustained traces are required.
•If program trace is recorded, the tool can (in the analysis stage) interpolate the time based on executed op-codes and thus compensate for deviations.
If you are designing the hardware which will include a trace port, please refer to the PCB Design Guidelines, which explain how the hardware should be designed to for optimal trace signal integrity.
On-Chip Trace Buffers (OCTB) are often available on devices with no Trace Port, to still enable recording trace, albeit in a limited size. The trace messages are stored directly to the trace buffer, which is a small part of the MCU memory, either dedicated for trace or user SRAM.
•FIFO overflows do not occur, as the trace is streamed directly to the trace buffer on the CPU.
•A low-end tool can read the trace buffer through the standard debug port (e.g. JTAG).
•The trace buffer RAM is relatively small compared to an external tool. Only short trace sessions are possible, which makes it generally unsuitable for system tests, which require longer trace sessions.
•Most OCTB systems don’t support streaming mode, so the activity can’t be displayed as it happens, but only after the trace is stopped.
•Most OCTB systems don’t provide an internal time stamp. On those that do, it typically records CPU cycles instead of a real time base; it is narrow and can thus overflow.
•Parallel trace of auxiliary events is not possible, as there is no time correlation between them.
•Introduction to Tracing - Webinar
•What is trace? - Video Tutorial