Chapter 7. Advanced Debugging Techniques

AVR32 Targets

Trace

The AVR ONE! features a Nexus 2.0 (IEEE-ISTO 5001-2003) compliant auxiliary port for receiving high-speed trace messages from AVR32 target devices. Refer to the appropriate AVR32 Technical Reference Manual, located on www.atmel.com/avr32 , for a full description of trace.

Three trace mechanisms are supported on the AVR32 OCD:

  • Program Trace

  • Data Trace

  • Ownership Trace

Program trace transmits messages at each program flow discontinuity (indirect branches and exceptions). Using these messages, front-end software is able to interpolate these messages to reconstruct the full program flow.

Data trace allows the developer to monitor read and write accesses of data memory on the target device.

Ownership trace allows an application executing on the target device to send messages to the debugger. This is typically used by an operating system to transmit the process ID to the debugger each time a new process is activated.

The AVR ONE! includes 128MB of DDR-SDRAM which is used to buffer trace messages in two different modes:

  • Streaming Trace Mode

  • Buffer Trace Mode

Streaming trace mode allows trace to be captured continuously. In theory this can be done indefinitely, although system resources may become limited. The volume of trace data depends upon the target clock frequency and the branch complexity of the program code being executed (which generates the trace messages). In this mode the DDR-SRAM onboard the AVR ONE! is used as an elasticity buffer, passing trace messages as quickly as possible to the USB controller and onwards to the front-end, whilst bufferring trace messages if this datapath is temporarily not serviced. Due to bandwidth requirements, streaming trace is only available when the AVR ONE! is enumerated on a USB 2.0 high-speed bus.

Buffer trace mode is used to capture trace in bursts. This could be a better option than streaming trace in certain circumstances, or if a USB 2.0 high-speed port is not available. The entire DDR-SRAM of the AVR ONE! will be used to store trace messages, in two configurations:

  • Halt-on-overflow mode will halt the CPU when the trace buffer is full. The trace messages can then be examined from the point of starting trace, until the point that the execution was halted.

  • Ignore-on-overflow mode will NOT halt the CPU when the trace buffer is full, but simply cause the AVR ONE! to stop storing further trace messages. This means that the trace messages can be examined without having affected code execution after stopping trace.

  • Wrapping mode will continuously overwrite existing trace messages with incoming messages, even though the old messages have not been read. When the CPU is finally halted, trace messages can be read out. These messages can be used to examine the program flow immediately before the CPU halted.

For further information on how to use trace with AVR32 Studio, see section Getting Started: Debugging with Trace

NOTE AVR ONE! does not support setting up trace using aWire.

EVTI / EVTO usage

The EVTI and EVTO pins provide features which can be used to ease debugging in certain scenarios. EVTI is used to signal an event INTO the target device, while EVTO is an event signalled OUT FROM the target device. The 38-pin MICTOR connector contains these two signals to allow the AVR ONE! access to these pins on the target device. EVTO can also be connected to pin 7 on the 10 pin JTAG connector for the AVR ONE! to be able to read it. Note that EVTO will only be available on the JTAG 10 pin connector if the target voltage is below 3.6 Volts for probe hardware revision 0. In order to use these pins externally during debugging, it is recommended to disconnect them from the AVR ONE! MICTOR connector on the application board.

EVTI can be used for the following purposes:

  • The target can be forced to stop execution in response to an external event. If the Event In Control (EIC) bits in the DC register are written to 0b01, high-to-low transition on the EVTI pin will generate a breakpoint condition. EVTI must remain low for one CPU clock cycle to guarantee that a breakpoint is triggered. The External Breakpoint bit (EXB) in DS is set when this occurs.

  • Generating trace synchronisation messages. This is a Nexus compliant feature which is not required by AVR32 target devices. A high-to-low transition on EVTI can be configured (using the EIC bits in DC) to generate trace synchronisation messages. The AVR ONE! will ignore these messages since they are not required for trace reconstruction.

EVTO can be used for the following purposes:

  • Indicating that the CPU has entered debug mode. Setting the EOS bits in DC to 0b01 causes the EVTO pin to be pulled low for one CPU clock cycle when the target device enters debug mode. This signal can be used as a trigger source for an external oscilloscope.

  • Indicating that the CPU has reached a breakpoint or watchpoint. By setting the EOC bit in a corresponding Breakpoint / Watchpoint Control Register, breakpoint or watchpoint status is indicated on the EVTO pin. The EOS bits in DC must be set to 0xb10 to enable this feature. The EVTO pin can then be connected to an external oscilloscope in order to examine watchpoint timing.

  • Generating trace timing signals. The AVR32 target can be configured to toggle every time a message is added to the trace transmit queue. This can be used to acquire more accurate timing information for trace output. This feature is currently not supported by the AVR ONE!