User manual

Atmel-ICE [USER GUIDE]
42330A-MCU-07/2014
31
8. Advanced Debugging Techniques
8.1 Atmel AVR UC3 Targets
8.1.1 EVTI / EVTO Usage
The EVTI and EVTO pins are not accessible on the Atmel-ICE. However, they can still be used in conjunction
with other external equipment.
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. Not used by the Atmel-ICE
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. Not used by the Atmel-ICE
8.2 debugWIRE Targets
8.2.1 Software Breakpoints
The debugWIRE OCD is drastically scaled down when compared to the Atmel megaAVR (JTAG) OCD. This
means that it does not have any program counter breakpoint comparators available to the user for debugging
purposes. One such comparator does exist for purposes of run-to-cursor and single-step operations, but user
breakpoints are not supported in hardware
Instead, the debugger must make use of the Atmel AVR BREAK instruction. This instruction can be placed
in FLASH, and when it is loaded for execution will cause the AVR CPU to enter stopped mode. To support
breakpoints during debugging, the debugger must insert a BREAK instruction into FLASH at the point at which
the users requests a breakpoint. The original instruction must be cached for later replacement. When single
stepping over a BREAK instruction, the debugger has to execute the original cached instruction in order to
preserve program behaviour. In extreme cases, the BREAK has to be removed from FLASH and replaced
later. All these scenarios can cause apparent delays when single stepping from breakpoints, which will be
exacerbated when the target clock frequency is very low.
It is thus recommended to observe the following guidelines, where possible:
● Always run the target at as high a frequency as possible during debugging. The debugWIRE physical
interface is clocked from the target clock
● Try to minimise on the number of breakpoint additions and removals, as each one require a FLASH page
to be replaced on the target
● Try to add or remove a small number of breakpoints at a time, to minimise the number of FLASH page
write operations
● If possible, avoid placing breakpoints on double-word instructions