File format:Trace32 ad

This page contains a description of the Lauterbach Trace32 logic analyzer file format.

Overview

Lauterbach Trace32 uses its .ad file as a container for several kinds of trace data. They not only contain totally different data structures but also different headers. The only way to know what's in the file is by looking at the textual header string at the beginning of the file.

The textual header string is part of the header, which is followed by data records. The file may either end after those records or continue with a set of practice commands that can be read back by Trace32 to configure the system the same way as when the measurement was made. We can use these to gather metadata.

The files can be compressed. Some compressions only affect the data records, others (zip) affect the entire file.

Even among the files created by the logic analyzers there are differences. But even if you know what to expect, the actual content may differ. Example: looking at the textual header string tells you indirectly whether the i.save or iprobe.save command was used to create the file. However, a debugging system may have both attached. This means that you may perform some measurements using a PowerIntegrator but may use the iprobe for others. Trace32 saves practice commands for both, so even if the file tells you which device was used, you may actually encounter practice commands referring to another. Currently, the import module doesn't handle this situation very well but at least it won't crash.

To make matters even more complicated, files created by Trace32's i.export.bin command should ideally be supported as well. Its format is more straightforward as it only contains a textual header and the data records. However, not all versions seem to create this kind of file. Instead, they contain files resembling the supported format but aren't yet fully understood.

Timestamps are given using a 12.8 GHz sample rate. The input module has to create packets to fill the void between data records as sigrok expects a linear sample flow. In order to keep the number of intermediate samples reasonable, the time stamps are reduced to represent a 200 MHz sample rate. If necessary, the scaling factor can be adjusted to allow for a higher sample rate - at the cost of higher memory usage.

Traditional format (AD_FORMAT_BINHDR)

Files with this format are created using the practice commands i.save and iprobe.save. The input module however currently only understands uncompressed files, so the /NoCompress switch has to be used. If you have files that are compressed, you may load them into PowerView and re-save them using /NoCompress. If loading doesn't work because you don't have the hardware attached, you can run PowerView by temporarily disabling all devices in the config.t32 file. Then, all traces can be loaded.

Header

Offset	Length	Description
0	32	A 32-character string containing the textual header string. It's includes a 0x1A terminator.
32	8	This uint64 contains the time where the trigger occured.
40	8	Unknown
48	1	The compression being used. 0x00 = no compression, 0x06 = /QuickCompress or /Compress were used.
49	4	Some config data, mostly unknown. It appears that byte #50 is different for the device used. It's 0x00 when a PowerIntegrator was used and 0x01 when an iprobe was used.
54	1	Unknown
55	1	This byte shows the sample rate: 0x00 for 250 MHz, 0x01 for 500 MHz.
56	1	This is the size of one data record.
57	2	Unknown
60	4	The number of records contained in the file.
64	4	The number of the last record. Counting doesn't necessarily start at 0, so the first record's number has to be calculated using this value as the base.
68	12	Unknown

Data Records

The content of the data records depend on the device that was used to capture the data. Currently supported are:

• LA-7940 PowerIntegrator
• LA-494x PowerIntegrator II
• LA-769x PowerTrace II IProbe

Devices that probably don't work but would be great for testing are:

• LA-793x ICD PowerProbe
• LA-4530 uTrace analog probe
• ...and anything older.

IProbe Data Records

These records have a length of 11 bytes.

Offset	Length	Description
0	8	A uint64 timestamp, indicating when this signal change occured
8	2	Current state of IP15..0 signals
10	1	Current state of CLK signal (IP16)

PowerIntegrator Data Records

These records have a length of 26 or 45 bytes, depending on the device and sampling rate used. At 250 MHz, the PowerIntegrator data records are 45 bytes. When using 500 MHz, the number of pods is cut in half, resulting in a record length of 26. This number of pods is also what's available on the PowerIntegrator II, so the same record length is used there.

Offset	Length	Description
0	8	A uint64 timestamp, indicating when this signal change occured
8	2	Current state of A15..0 signals
10	2	Current state of B15..0 signals
12	2	Current state of C15..0 signals
14	2	Current state of D15..0 signals
16	2	Current state of E15..0 signals
18	2	Current state of F15..0 signals
20	4	Unknown
24	2	Current state of J15..0 signals (not present in 500 MHz mode)
26	2	Current state of K15..0 signals (not present in 500 MHz mode)
28	2	Current state of L15..0 signals (not present in 500 MHz mode)
30	2	Current state of M15..0 signals (not present in 500 MHz mode)
32	2	Current state of N15..0 signals (not present in 500 MHz mode)
34	2	Current state of O15..0 signals (not present in 500 MHz mode)
36	4	Unknown (not present in 500 MHz mode)
40	1	Current state of signals CLKF..A (32=CLKF, .., 1=CLKA)
41	1	Current state of signals CLKO..J (32=CLKO .., 1=CLKJ, not present in 500 MHz mode)
42	3	Unknown

Practice Commands

The Practice commands follow this scheme:

Offset	Length	Description
0	4	Start indicator: "(((("
4		0x20, <Practice Command>, 0x0A
		...
	2	Length of the text data after the start indicator in bytes
	2	0x00 0x00
	4	End indicator: "))))"

For practical reasons, the import module simply splits up everything starting at byte 0 and tries to make sense of the pieces.

Binary Export Format (AD_FORMAT_TXTHDR)

TBD