AVR8_FAILURE_NO_OCD_CONTROL: Unable to gain control of OCD. Clock could be too fast.

[felias-fogg]

Hi @xedbg,

I was pulling my hair out about the error message in the subject line. It happened (deterministically) after I had set up a JTAG debug session by signing on, providing the context, activating, attaching, and then requesting a reset. The reset operation throws the exception. By commenting out some of the operations, I was also able to get error messages such as

• AVR8_FAILURE_ILLEGAL_OCD_STATUS: Read an OCD status that is illegal (reserved bits set)
• AVR8_FAILURE_ILLEGAL_STATE: Illegal run / stopped state when reading a value from SRAM

I got these messages in the context of JTAG debugging on, e.g., ATmega164PA, ATmega32A, ATmega644, ATmega128.

The puzzling thing is that it happens only with SNAP and PICKkit4, while Atmel-ICE, JATAGIC3, the Power-Debugger, and EDBG (on the 324PB Xplained Pro board) are completely happy and do not throw any exceptions at me.

Meanwhile, I have figured it out, I believe. SNAP and PICkit4 simply do not implement the finite state machine that I expected after reading Section 7.5 of the EDBG manual. Actually, I am not sure what kind of protocol they implemented. What I discovered is that changing between programming and debugging mode can be done safely by restarting the active session and activating debugging mode by enter_progmode followed by leave_progmode. There should be a more straightforward way, but I have not found it yet.

If you want to try it out by yourself, I came up with a small example demonstrating the issue. It can be downloaded from https://github.com/felias-fogg/avr_debugger_fsm.