An on-chip debug module is a system allowing a developer to monitor and control execution on a device from an external development platform, usually through a device known as a debugger or debug adapter.
With an OCD system the application can be executed whilst maintaining exact electrical and timing characteristics in the target system, while being able to stop execution conditionally or manually and inspect program flow and memory.
When in Run mode, the execution of code is completely independent of the Power Debugger. The Power Debugger will continuously monitor the target device to see if a break condition has occurred. When this happens the OCD system will interrogate the device through its debug interface, allowing the user to view the internal state of the device.
When a breakpoint is reached, the program execution is halted, but some I/O may continue to run as if no breakpoint had occurred. For example, assume that a USART transmit has just been initiated when a breakpoint is reached. In this case the USART continues to run at full speed completing the transmission, even though the core is in stopped mode.
The target OCD module contains a number of program counter comparators implemented in the hardware. When the program counter matches the value stored in one of the comparator registers, the OCD enters stopped mode. Since hardware breakpoints require dedicated hardware on the OCD module, the number of breakpoints available depends upon the size of the OCD module implemented on the target. Usually one such hardware comparator is ‘reserved’ by the debugger for internal use.
A software breakpoint is a BREAK instruction placed in program memory on the target device. When this instruction is loaded, program execution will break and the OCD enters stopped mode. To continue execution a "start" command has to be given from the OCD. Not all Atmel devices have OCD modules supporting the BREAK instruction.