How bloody hard can it be to program an AVR chip?

[EEVblog]

EDIT: THIS PROBLEM IS NOW FIXED, NO NEED TO REPLY WITH A SOLUTION, THANKS.

Trying to restore my bricked Makerbot Replicator.
Firmware is here:
https://github.com/makerbot/MightyBoardFirmware/tree/master/dist/MightyBoard

I simply cannot get AVRtsudio to read any if the .HEX formats - "unsupported format" error.

I uninstall VARstudio and try avrdude as recommended by Makerbot and everyone else.
avrdude cannot recognise my AVRISP-MkII programmer.
Yes, I've try the Win-LIB driver instead of jungo etc, no dice.

This is just shit.
I can't program a simple bloody AVR ATmega1280 chip. 

[firewalker]

Can't you use your general purpose programmer?

Alexander.

[firewalker]

BTW is there any GNU/Linux machine near you? I believe that it is a driver issue for avrdude. Usually those things tend to work better on GNU/Linux.

Alexander.

[firewalker]

Hust did a test:

Makerbot hex file:
file ATmegaBOOT_168_atmega1280.hex
ATmegaBOOT_168_atmega1280.hex: HTML document, UTF-8 Unicode text, with very long lines

Some of mine hex file produced with avr-gcc:
file pellet_burner.elf.hex
pellet_burner.elf.hex: ASCII text, with CRLF line terminators

This happens if you just right click and save the file from the page. Try to klick on the hex file link, press the RAW button and the save the file (right click, save page as).

file ATmegaBOOT_168_atmega1280.hex
ATmegaBOOT_168_atmega1280.hex: ASCII text, with CRLF line terminators

Give AVRStudio again a try.

Alexander.

[casper.bang]

As someone who literally just jumped into the MCU game a month ago, I must say I found it super easy to program an AVR chip.  It has to be said, I skipped the giant studio thing and keep things simply by just relying on the open source gcc compiler, avrdude and avrispmk II:

Compile:
avr-gcc -mmcu=attiny13a myprogram.c -o myprogram.o -Os

Link:
avr-objcopy -j .text -O ihex myprogram.o myprogram.hex

Program:
sudo avrdude -c avrispmkII -p attiny13 -U flash:w:myprogram.hex -P usb -e

I've recently started using make files pulled from WinAVR (Eric B. Weddington, Jurg Wunsch, et al.) which means I can build with "make all" and program with "make program", couldn't be simpler.

[IanB]

I simply cannot get AVRtsudio to read any if the .HEX formats - "unsupported format" error.

So if you're testing a circuit and an IC doesn't seem to work, do you keep trying different test instruments until you find one that says the chip is OK, or do you swap out the IC for a different one to make sure the chip isn't faulty?

If AVRStudio says a .HEX file is an unsupported format, then most likely the file is bad. Swap the HEX file for a different copy that isn't bad...

[bxs]

BTW is there any GNU/Linux machine near you? I believe that it is a driver issue for avrdude. Usually those things tend to work better on GNU/Linux.

Alexander.

+1

Dave if are +- lost with drivers just, give linux a try, you just need a livecd or liveusb linux

Of course I don't believe you will give Linux a try 

[c4757p]

It's just a hex file. The simplest file format in the world. Just break out Python or some other quick-as-hell scripting language and convert it to AVR Studio format... Seriously, that's a ten minute script. How much time have you already spent on this?

If AVRStudio says a .HEX file is an unsupported format, then most likely the file is bad. Swap the HEX file for a different copy that isn't bad...

Not necessarily. avrdude is pretty forgiving with the format, it'll happily take "poorly formatted" files that other programs will reject. It's entirely possible that the files were generated in some avrdude format variant and the guy who did it didn't know any better.

[casper.bang]

Dave if are +- lost with drivers just, give linux a try, you just need a livecd or liveusb linux

+1

If Dave does decide to go this route, it takes just 2 minutes to install the necessary software on any Debian derived distro (Debian/Ubuntu/Mint* etc.) with the command:
sudo apt-get install avrdude gcc-avr avr-libc gcc-avr binutils-avr

*What I am using.

[mikeselectricstuff]

Definitely something messed up with that download page - save link as downloads HTML, clicking on it takes you to a page displaying the hex file.
Maybe a github quirk. Once you get the actual hex it should load into AVR Studio OK

Considering this chip has a dedicated boot flash area with its own lock bits you have to wonder how it can get into a state that requires the use of a programmer - seems like a pretty incompetent bootloader.
 

[bxs]

Definitely something messed up with that download page - save link as downloads HTML, clicking on it takes you to a page displaying the hex file.
Maybe a github quirk. Once you get the actual hex it should load into AVR Studio OK

Considering this chip has a dedicated boot flash area with its own lock bits you have to wonder how it can get into a state that requires the use of a programmer - seems like a pretty incompetent bootloader.

This is how this git web browsers work, it's normal, for a direct link:
https://raw.github.com/makerbot/MightyBoardFirmware/master/dist/MightyBoard/ATmegaBOOT_168_atmega1280.hex

 

[c4757p]

That file is perfectly valid Intel HEX and the checksums are consistent. If AVR Studio won't load it, then either you're loading it wrong, you've downloaded a corrupted file, or AVR Studio is FUBAR.

Validator attached - expects the hex file to be piped in. If it's silent the file is good.

[Rufus]

Definitely something messed up with that download page - save link as downloads HTML, clicking on it takes you to a page displaying the hex file.

You can right click on the RAW button and save as to get the hex file. Stupid way to distribute that kind of file. Dave has probably been trying to program the HTML from the page.

[c4757p]

Stupid way to manage a software project that's indicative of people with no real software experience. The hex file is a build product, it shouldn't be stored in the version control tree, which is only for source. It should be generated from the source by the Makefile, which should have a build target to prepare .zip and .tar.bz2 packages for distribution. These should be offered from a home page somewhere for direct download.

Git is wonderful for handling huge source trees, so they don't seem to care about cluttering it up, but you should still keep your source tree relatively clean and not litter it with build products.

[IanB]

@c4757p: I understood you to be a student, but you seem to have a grasp of most subjects that is unusually mature for a student. Did you have industry experience before starting college?

[c4757p]

No, but I've always had a fascination with doing big projects and keeping up to date with industry practices, both with electronics and programming. I built a full compiler with proper build suite support and full documentation in 10th grade... I'm a lot more interested in the actual industries than most people I know, and my central area of interest is tools for use by other engineers (compilers, debuggers, T&M equipment).

[Kremmen]

Stupid way to manage a software project that's indicative of people with no real software experience. The hex file is a build product, it shouldn't be stored in the version control tree, which is only for source. It should be generated from the source by the Makefile, which should have a build target to prepare .zip and .tar.bz2 packages for distribution. These should be offered from a home page somewhere for direct download.

Git is wonderful for handling huge source trees, so they don't seem to care about cluttering it up, but you should still keep your source tree relatively clean and not litter it with build products.

Normally you would have the source version control system dedicated to the development organization. They would then create binaries that are release labeled and stored separately in an artifact repository. The artifacts are installable packages or binaries, according to the nature of the toolchain and environment. Larger companies have IT Operations responsible for the day to day management and maintenance of the IT infra, and it is the responsifility of those guys to install any new software and upgrade/update the existing stuff. They only ever care about the binaries or whatever the form of the install package happens to be, but never the source code. So you need to provide them with just that.

The open source scene perhaps works a bit differently since the point is that the source is available for anyone interested. The developers may also provide binaries - this makes sense if it is not certain that the targeted users have a development environment available. The question then is where should the binaries be stored? I am not intimately familiar with Git as i only use it as a client, never as a developer. But yes, the build artifacts should not be stored mixed with the source.

[TerminalJack505]

Back in the good ol' days when storage space was much more expensive I remember having to deal with managers that thought the version control system was a great place to store (non-build dependent) binaries.  (Usually the build results.)

The developers would have to explain that the deltas between the different versions would be huge and that this practice would chew-up space unnecessarily.  Basically, we would argue, version control software wasn't meant for this purpose.  And, yes, we didn't want all that crap polluting the revision database, but this was a valid argument.

I guess, anymore--storage space being as cheap as it is--this isn't as bad as it once was.  Revision control software is probably a lot smarter as well with regards to binaries.

[IanB]

There are circumstances in which you might put build products under source control. For instance, suppose you have a large project that depends on contributed or third party packages for some of its functionality. It may not be possible or practical to compile the entire thing from source every time. In this case some of your packaged binaries may be inputs to the master build and as inputs they should be in version control just like source files.

[madires]

Stupid way to manage a software project that's indicative of people with no real software experience. The hex file is a build product, it shouldn't be stored in the version control tree, which is only for source. It should be generated from the source by the Makefile, which should have a build target to prepare .zip and .tar.bz2 packages for distribution. These should be offered from a home page somewhere for direct download.

Git is wonderful for handling huge source trees, so they don't seem to care about cluttering it up, but you should still keep your source tree relatively clean and not litter it with build products.

The version control systems are great for collaborating and tracking changes. The problem with the well known OSS sites is that everything has to be inside the repository. Otherwise one would have to setup an own webpage and the simplicity of using github or whatever is lost. Another issue is that more and more of those sites are removing direct downloads because some clever bad boys figured out how to misuse the download feature to distribute copyrighted content.

[c4757p]

Nothing wrong with setting up your own web page, in fact, if you manage a software project you should do that. The simplicity of GitHub is in the code management features. AFAIK, they don't provide website functionality, and what they do provide doesn't need to be perverted for that purpose.

Now, it's perfectly reasonable to use version control separately for built projects (it's not unusual for entire websites to be inside VCS), but not in a subdirectory of the source code tree, and you certainly shouldn't make your users dick around with the VCS ever, ever, ever.

If the site is removing direct download then it's no longer suitable for use and should be abandoned. Sites like SourceForge still do direct download without issue, and as bxs demonstrated, so does GitHub.

[EEVblog]

Go to the Tools menu, select device programming, set your device and load the hex file. Very easy when you know how.

That's exactly what I did. I know how to use AVRstudio, I've used it before. It does not work, it says the HEX file is unsupported.

[EEVblog]

Considering this chip has a dedicated boot flash area with its own lock bits you have to wonder how it can get into a state that requires the use of a programmer - seems like a pretty incompetent bootloader.

Yes, the Makerbot firmware upload process is complete crap, and is a very well known issue. Lots of people have bricked their Makerbots like I did using their own firmware upload tool.

[EEVblog]

It's just a hex file. The simplest file format in the world. Just break out Python or some other quick-as-hell scripting language and convert it to AVR Studio format... Seriously, that's a ten minute script. How much time have you already spent on this?

I have no idea how to use python (I could learn)
I have no idea how to write such a script (I could learn)
I have no idea about the HEX file format (I used to a long lone time ago, I could learn again)

But the point is:
I should not have to learn it
I should not have to write a script
I should not have to convert formats

[IanB]

Now, it's perfectly reasonable to use version control separately for built projects (it's not unusual for entire websites to be inside VCS), but not in a subdirectory of the source code tree, and you certainly shouldn't make your users dick around with the VCS ever, ever, ever.

Suppose your product release 1.3 depends on Vendor Library 2.4.3 (with two patches and three hotfixes), and a year later someone wants to come back and recreate release 1.3 exactly from source to debug a problem. If they get a build failure, "missing dependency, Vendor Library 2.4.3 not found", they are going to be somewhat frustrated. There are times when dependent libraries and third party contributions ought to be in the source tree under version control, so you can recreate an exact copy of an earlier build.

There is nothing worse than needing to make a critical 1.3.0.1 patch to fix an urgent problem and finding you cannot recover the exact version of Vendor Library that went into the original 1.3 release...