Important:
It is important to leave the SPIEN fuse programmed, the RSTDISBL fuse unprogrammed! Not doing this
will render the device stuck in debugWIRE mode, and High-Voltage programming will be required to revert
the DWEN setting.
To disable the debugWIRE interface, use High-Voltage programming to unprogram the DWEN fuse. Alternately, use
the debugWIRE interface itself to temporarily disable itself, which will allow SPI programming to take place, provided
that the SPIEN fuse is set.
Important:
If the SPIEN fuse was NOT left programmed, the software front-end will not be able to complete this
operation, and High-Voltage programming must be used.
In MPLAB X IDE if debugWIRE is enabled on the target device and a SPI programming session is attempted MPLAB
will offer to disable debugWIRE first. In Atmel Studio this must be done manually by, during a debug session, select
the 'Disable debugWIRE and Close' menu option from the 'Debug' menu. DebugWIRE will be temporarily disabled,
and the software front-end will use SPI programming to unprogram the DWEN fuse.
Having the DWEN fuse programmed enables some parts of the clock system to be running in all sleep modes. This
will increase the power consumption of the AVR while in sleep modes. The DWEN Fuse should therefore always be
disabled when debugWIRE is not used.
When designing a target application PCB where debugWIRE will be used, the following considerations must be made
for correct operation:
•
Pull-up resistors on the dW/(RESET) line must not be smaller (stronger) than 10 kΩ. The pull-up resistor is not
required for debugWIRE functionality, since the debugger tool provides this.
•
Any stabilizing capacitor connected to the RESET pin must be disconnected when using debugWIRE, since they
will interfere with correct operation of the interface
•
All external Reset sources or other active drivers on the RESET line must be disconnected, since they may
interfere with the correct operation of the interface
Never program the lock-bits on the target device. The debugWIRE interface requires that lock-bits are cleared in
order to function correctly.
4.4.15
debugWIRE Software Breakpoints
The debugWIRE OCD is drastically scaled down when compared to the Microchip 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-stepping operations, but
additional user breakpoints are not supported in hardware.
Instead, the debugger must make use of the AVR BREAK instruction. This instruction can be placed in FLASH, and
when it is loaded for execution it 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 behavior. 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 minimize on the number of breakpoint additions and removals, as each one require a FLASH page to be
replaced on the target
©
2020 Microchip Technology Inc.
User Guide
Power Debugger
On-chip Debugging
DS40002201A-page 74
Need help?
Do you have a question about the Power Debugger and is the answer not in the manual?