Avrdude output deciphering help needed

[ve7xen]

Of course, this all begs the question, what's the easiest way to implement a clock with my rig so I can use it to program both bootloader and non-bootloader chips with the same board.  If the SCK sends a clock signal, why can't that be used?  And what does that signal have to connect to?

Easiest is probably to use a TTL can oscillator. Get an 8MHz one, plug it into 5V and the clock in on the AVR. Should work with any chip regardless of the CKSEL fuses.

The SCK signal can't be used because one of the requirements of the ISP interface is that the clock is 1/4 or slower than the system clock, so it can't also be the system clock source. Also the AVR needs a clock for its internal operation between serial commands (when SCK is quiet). I'm sure it would be possible for them to engineer the protocol and chip to steal a clock from the ISP connector somehow, but this would increase complexity and cost. ISP is for "In-Circuit" serial programming, so they assume you have the basic requirements of the system provided (pretty much just power and system clock).

[bingo600]

Or just use an AVR (Internal 8Mhz clock) , should get you 4Mhz out.
The 4Mhz can be used as clock for the target avr.

/Bingo

[chipwitch]

We aren't talking about "Arduino" here, we're talking about AVR, since you're starting from bare chips and trying to use ISP programming (while Arduino typically uses the bootloader for loading code).

Yes, I'm fully aware of the distinction.  I want the power of working outside the boundaries of Arduino.  I hate boundaries

I've worked with AVR for years, before Arduino existed.

And THAT is precisely why I asked!  I am so fascinated by Arduino as a marketing marvel.  They single-handedly (so to speak) generated boosted sales for Atmel by essentially creating a market.  No advertising campaign could have even been conceived for such a purpose, I don't believe. Arduino (and I suppose the PIC people) pretty much made microcontrollers mainstream.  From my approach to MCU's, I haven't had the opportunity to meet many of those relatively few like yourself, who worked with MCU's when all you had to go on was the datasheet.  I mean, if we aren't there already the day is fast approaching where the "normal" way one becomes acquainted with MCU's will be via prepackaged, easy to use, high level language based interfaces, such as Arduino or PIC.  I'm a geek.  What can I say?  I find it fascinating from the cultural perspective.  It wasn't all that long ago, the ONLY option one had to program MCUs was assembly language.  I guess what I'm saying is for me and many, many people like me, we will learn assembly because of the doors Arduino open for us.  Where you and others, if you have any interest in Arduino at all, will be learning in the opposite direction.   

The signature and some calibration values are stored in a special page of flash that isn't accessible via standard ISP. In double checking some things to respond to you here I found someone reporting on an undocumented ISP command that can enable you to write this data, and that it's possible for it to get corrupted if the right bit gets flipped during programming. Other than that though it's basically read-only, as designed.

The reason I asked, is avrdude isn't recognizing the signature of some of the chips I have.  I think it's because there's no external clock.  These chips have bootloaders.  Now that I know, I'll throw a crystal on the board and see what happens.

[dannyf]

It wasn't all that long ago

You mean in the 1980s?

when all you had to go on was the datasheet.

I would still argue that reading the datasheet is by far the best way to learn a mcu.

[chipwitch]

I mounted a 3-pin sip header and a couple 22 pF caps to my programming rig.  That way, I can plug in whatever crystal I want to use, if any.  I have now successfully uploaded sketches to every atmega chip I own with the programmer, including the ones with a bootloader.  I guess  that concludes this thread.

[nitro2k01]

I'm developing a product using an FTDI+AVR combo and I can share some advice. I'm allowing two different programming methods, bitbang through the FTDI inteface, mainly used for burning the bootloader, and a bootloader which communicates over the serial line. I'm also using the FTDI as an external clock source instead of using a crystal.

At first I had difficulty programming the chip. What I finally found out is that the chip needs a clock source in order to work, and that the clock needs to be fast enough for the programming. The device comes shipped with the fuses set to use the internal RC oscillator to allow the chip to be programmed, which is spelled out explicitly in the datasheet.

The device is shipped with internal RC oscillator at 8.0MHz and with the fuse CKDIV8 programmed, resulting in 1.0MHz system clock. The tartup time is set to maximum and time-out period enabled. (CKSEL = "0010", SUT = "10", CKDIV8 = "0"). The default setting ensures that all users can make their desired clock source setting using any available programming interface.

If you program the CKSEL fuses to use anything but the internal RC oscillator before providing an external clock source of any description, you're screwed until and unless you can program the chip with such a clock present. The downside of the default setting is that you need to program the chip at a slower clock rate, which can be a pain. I had luck with using the -B 1.0 avrdude switch, which sets the bit clock of the programmer to 1 µs. The exact interpretation of the switch might vary between programmers, so experiment with the value if needed.

In my case, since I had an external high speed clock available, my programming procedure would be to first program the fuses using the -B 1.0 option, then to program the flash with no -B flag (to get the fastest programming speed possible for programming the flash.) A more appropriate procedure for you is probably to program everything using -B 1.0 or a slower setting, and also to program LFUSE last – LFUSE is where the clock source selection fuse lies on Atmega328 – so that you don't lock yourself out of the chip until you're ready to put in its final circuit, where you hopefully have an appropriate crystal.

[dannyf]

I mounted a 3-pin sip header and a couple 22 pF caps to my programming rig.

It will work with no load capacitors as well - just slightly faster than spec.

[Flenser]

I retried the usbtiny, with the exact same everything (except changing the controller on the command line, obviously) and it seems to be faulty.

Chipwitch,

From your original screendump, the avrdude command you are using for the usbtiny could be wrong.

The adafruit site http://learn.adafruit.com/usbtinyisp/avrdude gives this example command and there is no "-P" option:
avrdude -c usbtiny -p m8

The avrdude manual explains that the "-P" option is used for the usbtiny when there are two or more usbtiny's on the USB bus http://www.nongnu.org/avrdude/user-manual/avrdude_4.html

The -P option you need to use to distinguish between multiple usbtinys on windows is much more obsure than what you have used. From my reading your use of "-P USB" would be expected to produce an error message before avrdude even tries to communicate with the usbtiny.

Try you usbtiny again without the -P option and with -vvvv. You might find that there is nothing wrong with your programmer.

[chipwitch]

avrdude command line is case sensitive.  -p is for "programmer".  -P (upper case) is for "port"

Also of note, for some reason I'm unable to explain, even though avrdude is supposed to default to the right port, according to adafruit's tutorial (for usb, at least), in my case, it would not.  I don't know if that was due to my system configuration or what.  In any case, one problem I was having is that "USB" is different than "usb" as far as avrdude is concerned, and it will choke.  Perhaps this isn't the case on other systems, but it is on both of mine, an XP and 7-64.  Something to be aware of.

[ve7xen]

I don't know how it is on Windows, but on Linux the USBtiny will work without any -P option.

[chipwitch]

Would that be specific to the controller?  I wouldn't think the the controller would care what the computer OS called the port.  The experience to which I referred in my previous post was with the AVRISP MKII controller.  I assure you, I have to have the -P usb.  Tried it with, without, ucase and lcase on two different windows machines.

I downloaded a nice little gui for avrdude called "AVRDudess," http://blog.zakkemble.co.uk/avrdudess-a-gui-for-avrdude/.  You can change and read fuses and everything.  At the bottom of the link, you can see the exchange I had with the gui's creator regarding this issue.  His program populates a drop down menu in the program for selecting the correct port.  It wouldn't work either because of the ucase "USB."  Strange quirk, but there you have it.

[GiskardReventlov]

avrdude command line is case sensitive.  -p is for "programmer".  -P (upper case) is for "port"

In any case, one problem I was having is that "USB" is different than "usb" as far as avrdude is concerned, and it will choke.

It chokes because it's case-sensitive.

[chipwitch]

Is it?

[nitro2k01]

Is it?

Yes and no. Everything that is given as a string (ie in quotes) in avrdude.conf is case-insensitive. Everything that is not given in quotes is matched verbatim, and thus case sensitive. So, why yes and no? Recently (starting  with avrdude 6.x I think) the type attribute in the config file was changed from an attribute to a string. So where it used to say type  = usbasp; it now says type  = "usbasp"; for example. The former is case sensitive, wile the latter is not. I believe all such attributes (such as programmer type) given on the command line are and were always case insensitive. The switches themselves, such as -p and -P are of course case sensitive anyway.

[Flenser]

-p is for "programmer".  -P (upper case) is for "port"
In any case, one problem I was having is that "USB" is different than "usb" as far as avrdude is concerned, and it will choke.

Yes -P (upper case)  is for "port" but the point I was trying to make was that  when you are using a USB programmer the value for the -P option is _never_ "USB" or "usb"

Avrdude knows from it's config file whether your programmer uses the USB, serial or parallel ports.

The usbtiny programmer can only be on the USB bus and so you don't specify "USB" as a parameter anywhere on the command line.

My suggestion was that you try your usbtiny with the command "avrdude -c usbtiny -p m328p" to see if you get past the "programmer operation not supported" message This appears to be a  message from avrdude complaining about your command line options and not a message about a problem getting a response from the atmega.

[chipwitch]

I'll try it with the usbTiny, but it does seem unlikely that the usbTiny will be different from the avrispmkii in that regard.

Things I've already posted:

Ve7xen... you da man!  Got it.  I think there were several things going on.  Driver conflicts etc.  I tried a never before programmed 328p, without the label, with the MK II controller and it worked!!  I retried the usbtiny, with the exact same everything (except changing the controller on the command line, obviously) and it seems to be faulty.

and...

I mounted a 3-pin sip header and a couple 22 pF caps to my programming rig.  That way, I can plug in whatever crystal I want to use, if any.  I have now successfully uploaded sketches to every atmega chip I own with the programmer, including the ones with a bootloader.  I guess  that concludes this thread.

Admittedly, it was only with the avrisp mkii

avrdude command line is case sensitive.  -p is for "programmer".  -P (upper case) is for "port"

Also of note, for some reason I'm unable to explain, even though avrdude is supposed to default to the right port, according to adafruit's tutorial (for usb, at least), in my case, it would not.  I don't know if that was due to my system configuration or what.  In any case, one problem I was having is that "USB" is different than "usb" as far as avrdude is concerned, and it will choke.  Perhaps this isn't the case on other systems, but it is on both of mine, an XP and 7-64.  Something to be aware of.

Okay, so maybe it's something other than avrdude.  I admittedly know NOTHING about avrdude that I didn't learn in the last two days.

Would that be specific to the controller? I wouldn't think the the controller would care what the computer OS called the port.  The experience to which I referred in my previous post was with the AVRISP MKII controller. I assure you, I have to have the -P usb. Tried it with, without, ucase and lcase on two different windows machines.

I don't know how to be more clear.

And then your comment:

Yes -P (upper case)  is for "port" but the point I was trying to make was that  when you are using a USB programmer the value for the -P option is _never_ "USB" or "usb"

Am I lying?  My experience is contrary to that.

Avrdude knows from it's config file whether your programmer uses the USB, serial or parallel ports.

Not in my experience.  The very first way I ever tried this was without the -P.  I even went back and tried it without the -P after getting everything to work with it.  No joy.
 

The usbtiny programmer can only be on the USB bus and so you don't specify "USB" as a parameter anywhere on the command line.

My suggestion was that you try your usbtiny with the command "avrdude -c usbtiny -p m328p" to see if you get past the "programmer operation not supported" message This appears to be a  message from avrdude complaining about your command line options and not a message about a problem getting a response from the atmega.

I'll repeat it... already tried this.

I'm not pretending to know why this is happening on my two systems, but it is.  If it's happening on my system, then it could happen on someone elses. And THAT was the point I was trying to make.  Just putting it out there in case someone else has a problem.  Maybe avrdude isn't supposed to work like it is on my machine.  Maybe there's some software on my system that is causing the problem and avrdude has nothing to do with it.  Maybe it's a hardware issue.  I have no idea and am only mildly curious as to what the ultimate culprit is.  I really don't object to having to put in the "usb."   Which I will once again assure you I need to do on MY two machines.