AVR studio Error "Got 0xc0, expected 0x00"

Question

so I have 5 board that uses an ATmega 2560 that I designed. They are all wired properly and initially were able to communicate with the AtmelStudio studio using an AVRISP mk2. The first board was able to flash, have the lock bit set and the fuses set, after which it would still be able to communicate with the programmer. The second board was initally able to flash the program, and have the lock bit set, but after setting the fuses I got the error:

"Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool)

Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device."

I was unable to even read the device signature. I thought maybe it was faulty chip, and since I had 3 other boards to work with I just ignored it. When programming the 3rd board, I went through the same procedure and the same error came up. But the 4th board worked when doing the same thing.

I'm still new to the AVR scene and would appreciate any help to get the broken 2 boards to work. I know its not something that's wrong with the crystal (16MHz), or the programmer, or even the ISP clock (125kHz). & its not something with the wiring. I tried erasing the faulty chips but an unable to do so and kept get the same error. Is there a way to make the chips reset to stock, or just to be able to reestablish communications with the chip.

The procedure was as follows: 1) flashed the chip 2) set lock bit to "0xCF" 3) set fuses to "EXTENDED 0xFD", "HIGH 0xD8", "LOW 0xFF" 4) flash chip again and receive error.

Answer 1

LOW fuse 0xFF means CKSEL3:0 bits are 0b1111. That means the low power crystal oscillator is selected (please refer 10.4 on page 40 of the datasheet).

Low power oscillator could be unstable when driving 16 MHz crystal, and unable to drive a ceramic resonator more than 10 MHz. It may be very sensitive to the schematic implementation and noise. Instead of it, it is better to use full-swing oscillator (low fuse byte 0xF7). Check schematic implementation, type of the resonator and capacitance on XTAL pins.

To restore ISP connectivity, you can unsolder the resonator, and apply about 1 MHz square wave on the XTAL1 pin (refer to 30.8 on page 339 of the datasheet).

Answer 2

I got this error on I started debuging in Atmel Studio 7.

1. On question about enable the DWEN fuse chose Yes
2. Then stopped Debugging and went to Device Programming->Device information->Reload.
3. Solution is go back to debugging (continue with F5) and end debugging with Debug->Disable debugWire and Close.

So if debugging is run then Device Programming is blocked and above error is showed.

Answer 3

I got with the same error message to this thread, my cause was an other one. I did confuse MISO and MOSI.

So how ever, the line MISO from you ISP/Debugger/Atmle-ICE/etc. goes to the MISO-Pin of your Atmel-Controller. MOSI goes to MOSI. Same lanble to same lable.

So there is no crossover like the serial TX->RX RX->TX stuff etc.

Answer 4

Try this information from Microchip studio. It fixed my problem. The debug wire was set from using another ide and session.

https://microchipsupport.force.com/s/article/ATmega328P-XMINI---Failed-to-enter-programming-mode

Answer 5

I was able to fix this issue using the article provided with some extra steps. Given that this issue was posted more than a year ago, I hope you have already figured it out.

1. Right-click on your application and select properties properties

2. Select tool on the left and change the tool from isp to debugWire and save (ctrl+s) tool

3)From there go to the debug menu and select Start Debugging and Break

4. Once the debugger has started, go back to the debug menu and select Disable debugWire and close.

5. close Microchip/Atmel Studio and restart it.

Once the studio opens back up open your application and follow steps 1 and 2 to switch the tool back to isp.

I hope this helps someone else running into this issue.

Answer 6

In my case there were two causes: first bad connection of one of the programmer pins in the board, and second wrong micronctroller selected (ATmega88 instead of ATmega88PA).

Answer 7

I had this issue, it was caused by me accidentally and unknowingly setting the LOW.SUT_SKSEL fuse to require an external oscillator. I simply added generated 4mhz signal to the one-side of the 16 mhz crystal. Then i brought up the device programmer using Atmel studio 7.0. With the generator present it read the signature without error, i fixed the error in the fuses and saved it. I was able to switch the signal generator off and use as normal. No soldering necessary!