Welcome, Guest

Author Topic: AVR mkII reading device signature then dissapearing  (Read 1090 times)


  • Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
AVR mkII reading device signature then dissapearing
« on: February 09, 2017, 08:09:05 PM »
Howdy guys! I am working for a senior design team here at Texas A&M and we are currently attempting to program an ATmega 2560 chip that is soldered onto a breakout board with header pins. We are trying to hardwire our AVR mkII programmer directly to the breakout board along with the help of a breadboard (which is crappy i know). We have went through hell to get to where we are now, but we finally were able to read the device signature of our chip. Once that showed up, I then proceeded to change the fuses to my desired values and went to click program. Then it fails and reads an error message saying "cannot complete command due to failure of a previous command" or something similar. Then all of a sudden the device signature is gone and I attempt to read it again and we get the dreaded error of "Cannot enter programming mode continue to pull your hair out". Then we aren't able to read the device signature at all again. This has happened twice on two different occasions. My assumption is that when we are attempting to program the fuses, something is happening that is causing the chip to "get out of programming mode" or "reset" or "playing hide and seek". Keep in mind this is our first attempts at connecting this up and we are hoping that this is a simple fundamental mistake that we are overlooking. If anyone has any information it would be greatly appreciated. These are the other two posts we have created over at AVR-freaks if you want more information.


  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1642
  • Karma: +42/-2
Re: AVR mkII reading device signature then dissapearing
« Reply #1 on: February 10, 2017, 09:38:34 AM »
Well, it is obvious that it is something related to the fuses that you set. What are the values that you try to program? You can accidentally disable ISP programming if you are using wrong fuse values. Quite often the most problematic fuses are the one that define the source of the clock. Double check the values.

Best regards,
Technical support and documentation manager at Olimex