Unknown Status 0x00 error when burning bootloader

Y'all-

I have been attempting to resolve a problem that I am experiencing when burning the bootloader onto a custom board. I've been working on this Arduino-based project for a while now, but this is the first time I have seen this problem. Although it's been posted before, I decided to create my own thread rather than dovetail onto another. So for review and clarity, here is the error I am seeing:

avrdude: stk500v2_command (): command failed
avrdude: stk500v2_program_enable (): bad AVRISPmkII connection status: 0x00 Unknown status
avrdude: initialization failed, rc = -1
          Double check connections and try again, or use-F to override
          this check.

Here are all of the pertinent details that I can think of at the moment (it's late):

Board uC: Bobuino, 1284 based (this is CrossRoads' product, or I should say a variant of that product)
Bootloader: optiboot
Programmer: AVR ISP mkII (first USB port on my laptop)
Board power: Via USB from the second USB port, via an FTDI -> serial breakout, which I have connected to the serial header on my board (this provides the external power that is needed when using the mkII)
Consistency: I feel relatively confident that the programmer isn't at fault because I can still use it to program sketches onto my devel boards

A little bit of background. Way way back, CrossRoads and I started with his Bobuino and removed stuff that my project didn't need, then added things I did. Over time the design morphed and changed like all projects do, but I was always able to burn the bootloader (once I had the correct drivers installed on my laptop of course). So. I had a fully working development board. Therefore it was time to move on to the production boards. Only a couple of changes were made. One change was to switch to SMT components for the crystals (1-uC, 1-RTC). I mention that because perhaps it is related to the problem, but that is just a stab. It's one of the differences between devel and prod boards. Anyway, I attempted to burn the same bootloader onto the production boards that I had burned onto the devel boards and that's when I encountered this problem. I inquired with Cross about it but he hasn't really ever seen the problem too much. So I did a Google search and found that this error has been encountered previously with several different board types. In one case the guy had a faulty AND gate that wasn't allowing the RESET pin to be brought low; in another the guy found a fault in his design. Still in other cases the problem was the speed with which the bootloader was being burned.

So naturally I have tried the remedies for all of those problems (hardwiring RESET to low, checking the circuit with my DVMM, etc.), but nothing has worked. I still get the error or some variant of an invalid signature error. Being a UNIX software type, I decided to delve into using avrdude directly (although I'm using Win7 to connect). In so doing, here is the output from one of the attempts that I made to reset the fuses:

c:\Program Files (x86)\Arduino\hardware\tools\avr\bin>avrdude -C ..\etc\avrdude.
conf -p m1284p -c avrispmkII -P usb -B250 -vvvv -U lfuse:w:0xff:m -U hfuse:w:0xd
e:m -U efuse:w:0xfd:m

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "..\etc\avrdude.conf"

         Using Port                    : usb
         Using Programmer              : avrispmkII
         Setting bit clk period        : 250.0
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200147136
avrdude: usbdev_open(): using read endpoint 0x82
avrdude: Sent: . [01]
avrdude: Recv: . [01] . [00] . [0a] A [41] V [56] R [52] I [49] S [53] P [50] _
[5f] M [4d] K [4b] 2 [32]
avrdude: stk500v2_getsync(): found AVRISP mkII programmer
Using p = 261.57 us for SCK (param = 73)
avrdude: Sent: . [03] . [98]
avrdude: Recv: . [03] . [00] . [03]
avrdude: Sent: . [02] . [98] I [49]
avrdude: Recv: . [02] . [00]
         AVR Part                      : ATMEGA1284P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
           eeprom        65    10   128    0 no       4096    8      0  9000  90
00 0xff 0xff
                                  Block Poll               Page
      Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
W   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
-- ---------
     flash         65    10   256    0 yes    131072  256    512  4500  45
f 0xff
                            Block Poll               Page
Polled
     Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
adBack
     ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
------
     lock           0     0     0    0 no          1    0      0  9000  90
0 0x00
                            Block Poll               Page
Polled
     Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
adBack
     ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
------
     lfuse          0     0     0    0 no          1    0      0  9000  90
0 0x00
                            Block Poll               Page
Polled
     Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
adBack
     ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
------
     hfuse          0     0     0    0 no          1    0      0  9000  90
0 0x00
                            Block Poll               Page
Polled
     Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
adBack
     ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
------
     efuse          0     0     0    0 no          1    0      0  9000  90
0 0x00
                            Block Poll               Page
Polled
     Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
adBack
     ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
------
     signature      0     0     0    0 no          3    0      0     0
0 0x00
                            Block Poll               Page
Polled
     Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  Max
adBack
     ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ---
------
     calibration    0     0     0    0 no          1    0      0     0
0 0x00

   Programmer Type : STK500V2
   Description     : Atmel AVR ISP mkII
   Programmer Model: AVRISP mkII
avrdude: Sent: . [03] . [90]
avrdude: Recv: . [03] . [00] . [01]
avrdude: Sent: . [03] . [91]
avrdude: Recv: . [03] . [00] . [01]
avrdude: Sent: . [03] . [92]
avrdude: Recv: . [03] . [00] . [0a]
         Hardware Version: 1
         Firmware Version Master : 1.10
avrdude: Sent: . [03] . [94]
avrdude: Recv: . [03] . [00] 0 [30]
         Vtarget         : 4.8 V
avrdude: Sent: . [03] . [98]
avrdude: Recv: . [03] . [00] I [49]
         SCK period      : 261.57 us

avrdude: Sent: . [10] . [c8] d [64] . [19]   [20] . [00] S [53] . [03] . [ac] S
[53] . [00] . [00]
avrdude: Recv: . [10] . [00]
avrdude: AVR device initialized and ready to accept instructions

Reading |                                                    | 0% 0.00s
avrdude:
Sent: . [1d] . [04] . [04] . [00] 0 [30] . [00] . [00] . [00]
avrdude: Recv: . [1d] . [00] . [00] 0 [30] . [00] . [1e] . [00]
avrdude: Sent: . [1d] . [04] . [04] . [00] 0 [30] . [00] . [01] . [00]
avrdude: Recv: . [1d] . [00] . [00] . [00] . [00] . [00] . [00]
Reading | #################                                  | 33% 0.08s
avrdude:
 Sent: . [1d] . [04] . [04] . [00] 0 [30] . [00] . [02] . [00]
avrdude: Recv: . [1d] . [00] . [00] . [10] . [00] . [00] . [00]
Reading | ################################################## | 100% 0.15s

avrdude: Device signature = 0x1e0000
avrdude: Expected signature for ATMEGA1284P is 1E 97 05
         Double check chip, or use -F to override this check.
avrdude: Sent: . [11] . [01] . [01]
avrdude: Recv: . [11] . [00]

avrdude done.  Thank you.

And of course if I make repeated attempts at running avrdude, I can

Continued.

A subsequent attempt with the same command line had the same result, but a slightly different error:

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
         Double check connections and try again, or use -F to override
         this check.

Then this after a few more attempts (same command line):

avrdude: Device signature = 0x008000
avrdude: Expected signature for ATMEGA1284P is 1E 97 05
         Double check chip, or use -F to override this check.

The only thing that I haven't tried yet but that I've read about in other related threads is this notion of using an external clock to see if that will enable you to burn the bootloader. Mostly because I'm a software type and I'm not sure how you'd do that. (I have an idea about how to approach it but never actually attempted it)

I can make repeated attempts with avrdude and it sometimes results in seemingly-random signatures being returned.

Finally, I made three initial prod boards. All three exhibit this problem, so I have been thinking that it could be a design issue. And that is another reason that I mention the crystal change from through hole to SMT. That shouldn't have any effect, but it still seems worthy of mention.

Ok so I just don't know where to do from here. I did read one thread where the OP mentioned that he had traces running through his crystal and that he thought this might be the problem. I don't have that issue, but can post some of the schematic if it might help anyone diagnose the problem.

Anyway, I've been at it for several hours now. Falling asleep. Any help would be greatly appreciated because as of now I am dead in the water and going nowhere with this project.

Thanks!

It seems like a noise or voltage level problem, or a bad ground.
Are those FTDI signals only 3.3V signals or 5V ?
Do you have decoupling capacitors for the 5V ?
Can you measure the ground pins if they are really connected, perhaps you missed one and is not connected. The 1284 and the two 22pF grounds are the most important.

You keep telling that it could be something with the crystals, so perhaps it might just be that.
Perhaps you have bad batch. Or are they resonators ?
Can you try to replace one with an old crystal ?

Peter_n-
Thank you for the feedback. I am a software type, but will attempt to answer your questions anyway. XD

The FTDI breakout is only being used to convert from USB to serial. At this point I only have GND and +5V connected from the breakout to the serial header. So the answer to your question is that the FTDI is supplying +5V, not +3.3V.

Yes, there are decoupling capacitors for the +5V, just as there were on the devel boards, which all still work.

I spent a fair amount of time measuring voltages on my board with the DVMM. Everything seemed ok. I sent the results to Cross via email and he didn't see anything wrong, so...but I can measure again. Which ground pins would you want me to check? Just the 1284 and the crystal caps? "All of them" is my guess to your answer. XD BTW, I checked all of the +5V and GND pins on the 1284 and all were normal. I also checked to see if the RESET pin at the chip was being pulled low and it was. All of this was with a DVMM however. I don't own an oscilloscope and would prefer to not have to get one. I may need to ship my boards to Cross for evaluation, but am trying to solve the problem myself first. I'd like to learn (a) and (b) he's got a lot going on at the moment.

Yeah, you're correct, I mentioned the crystals. It's just one of the diffs between the devel and prod boards. And the only diff was from through hole to SMT. At every point I have used Cross's services to verify the designs and components. He's looked it over and says that it's ok.

I am pretty sure that they are crystals, not resonators. Here is the link to the RTC crystal (32 KHz):

and the link to the uC crystal (16 MHz):

I suppose I could solder in an old crystal, but they're through hole (sorry for the repeat) whereas the new ones are SMT, so I'm not sure how I'd go about doing that.

I thought I'd add a screen capture of the section of the board. In this section you can see the 1284, the ICSP header, the uC crystals, the RTC and its crystal. I don't see a problem with this arrangement, but I could be missing something.

I'm off to power up the board and check the grounds on the two uC crystal caps.

Thanks!

So far so good. I can't see a problem yet.

What about this:
avrdude: Device signature = 0x1e0000
avrdude: Expected signature for ATMEGA1284P is 1E 97 05

It seems that the first 1E is received and then the communication is lost. That is almost impossible, but if that would be true I can think of a few things.
There could be a bouncing ground. Can you check one more that the ground to the computer and to the programmer are okay ?
Can you use the programmer to power the board ?
Or you use a flat ribbon cable from the programmer to the ATmega chip. Or a breadboard with bad connections.

Ok I spent time checking the grounds and such. Recall that I only have a DVMM, no oscope. Here are the results:

1- uC cap grounds are solid 0.00V
2- PWR and GND are solid at the serial header and at a supplemental header
3- RESET is pulled up to +5V. I can (with dexterity) connect the DVMM's probes to the supplemental header and watch RESET change from +5V to 0.00V as I press the RESET button, then release it. It happens as consistently as you'd want to see.
4- I don't have a cap on the RTC's crystal. Cross had said that it was't necessary and only used for frequency trim. So it is one of the few components that isn't populated on my board.
5- All of the +5V and GND pins (4 and 4 in number) on the 1284 have solid readings. (+5.04V and 0.00V)
6- The +5V to +3.3V LDO shows the correct values of +5V in, good GND (0.00V) and +3.29V output.
7- The ICSP header shows correct values for PWR, GND and RESET. I can see RESET go low then back high when I press and release the RESET button too.
8- With the mkII programmer connected to the board and the board powered via the USB->FTDI->serial header as mentioned previously, I flipped the board over and checked the values on the backside of the ICSP header. PWR was +5.03V, GND was -0.00V and RESET was +5.03V. SCK, MOSI and MISO were (obviously) random values. Thus it would seem that the GND via the programmer is ok.

And you can't use the mkII programmer to power the board. That's well documented, so at least I didn't make that mistake. XD It won't do anything if you simply connect it to the ICSP header but don't supply external power to the board. Nada and you can't upload anything (and therefore screw something up) that way either.

So I dunno......I need to get this working because the entire project revolves around it (obviously). Therefore everything is dead in the water until I figure this out. Scary kinda, 'cause I'm in unknown territory. But that's never stopped me before. XD This entire project has been a great learning experience. Arduino stuff is crazy cool. Just wished that it worked "easier"...XD

Ok thanks

Can you get another programmer ? Or use an Arduino board as programmer. Perhaps your programmer is broken.
Can you make a photo of it ? With all the cables and wires and programmer ? It is only a last attempt, since I have absolutely no idea how to solve it without a storage scope for the ICSP programming signals.

I've never had an issue myself, but when was the last time you updated the firmware on the AVRisp MkII?

Peter_n:
Can you get another programmer ? Or use an Arduino board as programmer. Perhaps your programmer is broken.
Can you make a photo of it ? With all the cables and wires and programmer ? It is only a last attempt, since I have absolutely no idea how to solve it without a storage scope for the ICSP programming signals.

Sure, I am attaching a few photos of my mkII programmer, the board and the FTDI. I'm also uploading a short video to YouTube that I made a few minutes ago illustrating the problem. But I'm on a satellite connection, so it'll be a while before that's ready. XD

Thanks

FTDI.jpg

board.jpg

WendoNZ:
I've never had an issue myself, but when was the last time you updated the firmware on the AVRisp MkII?

Never. Is it important to update the firmware periodically? And how would I go about doing that?

Thanks

Try another programmer as Peter_n mentioned.

Thanks for the photos. That is only a short flat ribbon cable. That's okay, I use such cables myself for programming a bootloader.

Budvar10:
Try another programmer as Peter_n mentioned.

Ok I am willing to try anything at this point. But I'll have to order one, this is all I have.

Peter_n:
Thanks for the photos. That is only a short flat ribbon cable. That's okay, I use such cables myself for programming a bootloader.

Ok. Well, it is what came with the mkII programmer when I bought it new.

I gave up last night on uploading the video from home. WAY too long via satellite. So I am in a Kinko's now waiting for it to finish. But it's slower than I would have expected. Perhaps they restrict uploads somehow or YouTube is slow by nature. Who knows. This is faster than from home anyway. lol I'll post again with the link once the upload is ready. I'd appreciate any feedback y'all might have.

Thanks!

Here is the 5 minute video. Any feedback is appreciated, thanks!

Well I've done a fairly extensive search on how to update the mkII's firmware but am only finding references that involve using Atmel Studio, which I don't have installed. There is fleeting reference to using avrdude to do the same thing, but I cannot find good instructions on how to do that.

Anyone have a link or a step by step procedure they can share?

I'm ordering a new programmer tonight too, just to cover all bases. Essentially the procedure at this point is:

  1. Try to do the firmware update
  2. Try a new programmer

Thanks

Ok after a few hours of searching I cannot find a good description of how to update the mkII firmware using avrdude (and not Atmel Studio). I'm frustrated, so I'm headed to the outbuilding to work on my cars for a while. I did order a new mkII from the Atmel site, but with the holiday tomorrow, I would not expect it to arrive until towards the end of the week. Unfortunately.

I'll let everyone know what happens. I'm still interested in trying the firmware update, but need to find a good writeup to do that first.

A couple thoughts occurred watching the video
Can you change the fuses to output system clock on whatever pin that it comes out on? Put an LED on it, see if it's oscillating?
If MKii can't program properly, try Nick Gammon's Arduino as ISP sketch. Maybe the diagnostics there will tell us more.

Sure, my understanding is that you can reprogram the fuses as many times as you'd like. Bricking is a concern, but I don't think that is happening here. However, I would need to know what hex values to specify in the command line to do what you're asking. I don't know enough about what the fuse setting values mean in order to make that determination. Have any idea?

BTW, the fuse values that I have used thus far are the ones that are defined for bobuino in the boards.txt file, thus:

##############################################################

bobuino.name=Bobuino
bobuino.upload.protocol=arduino
bobuino.upload.maximum_size=130048
bobuino.upload.speed=115200
bobuino.bootloader.low_fuses=0xff
bobuino.bootloader.high_fuses=0xde
bobuino.bootloader.extended_fuses=0xfd
bobuino.bootloader.path=optiboot
bobuino.bootloader.file=optiboot_atmega1284p.hex
bobuino.bootloader.unlock_bits=0x3F
bobuino.bootloader.lock_bits=0x0F
bobuino.build.mcu=atmega1284p
bobuino.build.f_cpu=16000000L
#bobuino.build.core=arduino:arduino
bobuino.build.core=standard
bobuino.build.variant=bobuino