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

[IanB]

I don't think I'm being unreasonable

Oh, I don't think you are being unreasonable either, but I do think you are being unrealistic. The real world is much more complicated than you may imagine. Once you get out there you will find it is incredibly difficult to have reasoned, rational conversations with people you interact with...

[c4757p]

I don't think I'm being unrealistic either. The Makerbot is billed as a finished product, just look at their website. It is not acceptable for a finished product to have such an unfinished system for updates. Microsoft does not distribute Windows updates as a package of EXE and DLL files to be dragged into place, which is pretty much what they're doing if Dave had to go anywhere near a HEX file.

Now, if Dave screwed it up through his own doing, it's a bit more reasonable. If I just poke into C:\windows and delete some random file, I can expect some under-the-hood digging in my near future. But if, as I remember it, it barfed on a routine firmware update and bricked, than it's not acceptable at all.

[IanB]

It is not acceptable for a finished product to have such an unfinished system for updates.

No, it is not acceptable.

But wait until you get into the real world and start trying to present those simple requirements to your colleagues, when "organisational inertia" and "design by committee" get in your way. You will quickly become disillusioned.

[c4757p]

Oh, I understand why it doesn't get done. I'm not some idealist who thinks that if you just turn me loose in their company, I'd have things set straight in a month! Still, isn't it a fair criticism of them? Maybe some criticism from potential customers (well, I'm out I guess, I wouldn't buy one  ) would give these committee designers the kick in the ass they need...

[4to20Milliamps]

Here's what it looks like when you drag and drop the "hex" file into google chrome:

I guess they need to take some of that 400 million dollars and hire a programmer 

[westfw]

Lots of people have bricked their Makerbots like I did using their own firmware upload tool.

if it doesn't have somebody who can write a proper damn bootloader.

I'm curious how you expect the bootloader to protect against someone using "their own FW upload tool" ?
Disable non-bootloader based ISP programming?  I don't think that would be very well received...

That said, github *is* a lousy binary distribution mechanism, and it isn't acceptable to require that people do their own build.  Google code has separate source and "download" areas, which has its own problems.  In fact, the whole "open source" thing gets complicated real quick once you realize that most of the "customers" can't actually deal with "source."

It is not acceptable for a finished product to have such an unfinished system for updates.

It depends.  I used to work on a system that required the user to change 8x 32bit EPROMs to upgrade the firmware (after disassembling the box and extracting the cpu board, which was somewhat difficult.)  It was quite a successful product, at that.

I find it vaguely amusing, in a cynical way, the number of people on the Arduino forums and AVRFreaks, who claim that the Arduino system is too simplified and they want to learn "real programming", but who don't want to actually, say, read the chip datasheets.  "Users" are a fickle bunch.

All that said, *is* there a live-boot linux CD that is aimed specifically at firmware programming?  Something that will include the usual unix core, plus avrdude, and the microchip equivalent, and whatever other programming tools exist for linux and various chips, with appropriate licenses.  The idea would be to dispense with all these problems that people have getting the parallel port to work in various versions of windows (for example.)  "Boot this CD, put your .hex file on a flash drive, and execute THIS command."

It would be an interesting project for someone interested in tools to put together. (hint, hint...)

[c4757p]

It depends.  I used to work on a system that required the user to change 8x 32bit EPROMs to upgrade the firmware (after disassembling the box and extracting the cpu board, which was somewhat difficult.)  It was quite a successful product, at that.

Out of curiosity, how long ago was "used to"? There was definitely a time when this was acceptable (it tends to coincide with the time when EPROMs were used... )

I find it vaguely amusing, in a cynical way, the number of people on the Arduino forums and AVRFreaks, who claim that the Arduino system is too simplified and they want to learn "real programming", but who don't want to actually, say, read the chip datasheets.  "Users" are a fickle bunch.

A Makerbot is more materials than EE or programming, so you shouldn't have to interact with programming tools to use it. But Arduino is programming and EE rolled into one, and if you expect to be able to use it to its full capacity while remaining isolated from the realities of EE and programming, you're a doofus.

[westfw]

   

required the user to change 8x 32bit EPROMs to upgrade the firmware

Out of curiosity, how long ago was "used to"?

Early 1990s.

[4to20Milliamps]

I guess we could just call the makerbot helpline for $29.95 a minute and see if they can help us out.


The file does have a (.hex) extension when you download it.......it should be a hex file, but it's obviously not.

[westfw]

bricked their Makerbots like I did using their own firmware upload tool.

Dave, could you tell us what exactly you did (what "firmware upload tools" did you use?), so I know whether I should join the bootloader bashers or not?

[EEVblog]

I don't remember anything about driver issues. I just remember you complaining about not being able to find the EXE (a valid complaint, but Makerbot's fault, they should have pointed you in the right direction, or hell, provided the download), and then about the file format. What was the problem with that?

Finding the EXE was the first issue with avrdude I ran into. Next was the avrdude library file or whatever it is being the wrong type, then it was the avrdude no recognizing the AVRISP MkII programmer. I spent ages on that and never solved it, avrdude did not work for me after several hours of work trying. It seems I am not alone in this.
I did not tweet every issue I had.

[Bored@Work]

I don't remember anything about driver issues. I just remember you complaining about not being able to find the EXE (a valid complaint, but Makerbot's fault, they should have pointed you in the right direction, or hell, provided the download), and then about the file format. What was the problem with that?

Finding the EXE was the first issue with avrdude I ran into. Next was the avrdude library file or whatever it is being the wrong type, then it was the avrdude no recognizing the AVRISP MkII programmer. I spent ages on that and never solved it, avrdude did not work for me after several hours of work trying. It seems I am not alone in this.
I did not tweet every issue I had.

Did you check the hex file was a hex file?

[EEVblog]

Now, if Dave screwed it up through his own doing, it's a bit more reasonable. But if, as I remember it, it barfed on a routine firmware update and bricked, than it's not acceptable at all.

Yes, it was not my fault. I was using the proper and latest makerbot software, and simply tried to update the firmware when it asked me if I wanted to do that on program boot.
It actually tells you to essentially "dick around" with the timing of pressing the reset button half a second after you click the download button or whatever. It also tells you that the timing varies between PC's.
http://www.makerbot.com/support/replicator/documentation/firmware/

Hit upload, wait a fraction of a second, and then press the reset button. 1.8 It will take a little while, but soon you should see a message telling you that your firmware has been updated successfully.

If your firmware does not update successfully, don't worry -- the timing can be really tricky because it will vary a lot from computer to computer. Try different timings, like pressing the reset switch just before you hit the upload button, or waiting a full second between hitting the upload button and pressing the reset switch. The process of figuring out exactly when to press each button can be frustrating, but you can't harm your bot by getting the timing wrong. And once you have it right, you'll know what works best with your computer and you'll have a head start next time.

Once you see the "Firmware update succeeded!" message, you're set! Go back to printing with your exciting new firmware.

They are wrong about the "you can't harm your bot by getting the timing wrong" part because I bricked mine, and it seems I am not alone, this is not an uncommon thing to happen.
By "bricked" I mean the machine would not initialise the LCD (bar characters) rendering the machine unsuable, and the makerbot software still refused to update the firmware.
I actually have no idea if the bootloader was still in place and working, but from my point of view the machine was bricked and unusable and I had to resort to my AVR programmer tools to fix it.

[EEVblog]

Did you check the hex file was a hex file?

No, I said that.
That had nothing to do with the avrdude issue. That issue was to do with driver compatibility with my avrisp mkii

[EEVblog]

Dave, could you tell us what exactly you did (what "firmware upload tools" did you use?), so I know whether I should join the bootloader bashers or not?

I used the proper Makerware program.
I also tried the older Replicator G software, that didn't work either.

[EEVblog]

I finally fixed it.
Yes, it was the stupid HTML/HEX file thing.
With the correct hex file AVR Studio 6 read it no problems and downloaded the firmware without issue. My Replicator is no working again. Well, it works, but doesn't print well, back to square one there...
Thanks to those who pointed out my stupid github error.

[mikeselectricstuff]

You don't get, I shouldn't have to resort to that. The whole idea of anyone having to do that is just retarded.
It should be download hex file, program, the end.

Makerbot is (IMHO) not a commercial retail product, it is a geeky hobby user product. You should expect to be a techy person before you even go near it...

They are selling it. therefore it is a commercial product and there is no excuse for selling something with  such incompetently written and clearly insufficently tested firmware. Of course it is not reasonable for everything to be bug free, but a basic bootloader (if done properly) is very simple, and not hard to get right, and test thoroughly. As long as that is done right, any other firmware issues can be dealt with easily.

[firewalker]

About avrdude. I believe it uses libusb to talk to the specific programmer. If there is a driver in the system occupying the device avrdude may not work.

Alexander.

[EEVblog]

About avrdude. I believe it uses libusb to talk to the specific programmer. If there is a driver in the system occupying the device avrdude may not work.

Yes, I eventually realised that, so I removed avr studio + the AVR Jungo driver etc and installed the proper libusb driver or whatever it is. avrdude still didn't work. Apparently I am not alone, this is not an uncommon issue it seems, but definite fixes seem hard to come by.

[firewalker]

Why it was briked? Did you manage to find something wrong to their upgrade process?

I guess they are using a boot loader and the firmware gets uploaded via uart. Like arduino.

Was there any activity on the bot's serial interface? The bootloader died?

Alexander.

[mikeselectricstuff]

At the very least, MB should have put a "How to program firmware.txt" file on the github page - it is not reasonable to expect people to know that right-click save-as doesn't work as expected..

I'm curious how you expect the bootloader to protect against someone using "their own FW upload tool" ?

If the bootloader worked properly there would never be a need to use a seperate tool.
Obviously all bets are off as soon as someone hooks up to the ISP port.
.

Hit upload, wait a fraction of a second, and then press the reset button. 1.8 It will take a little while, but soon you should see a message telling you that your firmware has been updated successfully.

If your firmware does not update successfully, don't worry -- the timing can be really tricky because it will vary a lot from computer to computer. Try different timings, like pressing the reset switch just before you hit the upload button, or waiting a full second between hitting the upload button and pressing the reset switch. The process of figuring out exactly when to press each button can be frustrating, but you can't harm your bot by getting the timing wrong. And once you have it right, you'll know what works best with your computer and you'll have a head start next time.

Once you see the "Firmware update succeeded!" message, you're set! Go back to printing with your exciting new firmware.

WTF? Jeez what a bunch of idiots.

OK Makerbot, if you're listening, this how you do it properly :

1) Provide a mechanism for your application code to jump into the (write-protected) bootloader on command from the host with no other user interaction. You run the update code on the host and it just works. If the bootloader doesn't hear anything for a few secs, it should exit back into the application code (in case it somehow got entered accidentally).

2) As a fallback in the case of a bad download, provide a way to force entry to the bootloader at power-up, e.g. by holding one or more buttons down at power-up, no stupid timing windows.  Have a clear indication that the button sequence has worked - e.g. flash a LED or the display backlight while in bootloader mode.
If you don't have buttons available , then just wait a few secs at startup to see if the host is trying to talk to you.

3) You may also want to have the bootloader do a checksum on the app code before jumping into it to ensure it's valid - in some cases this is  just icing and not essential, although for a mechanical device that could suffer or cause damage if the software freaks, it would be irresponsible to not validate the code. The checksum can be generated by the PC software that does the firmware update, to avoid having to figure out how to get the AVR devtool to do it

That's it. Not hard. Half a day's work, couple of hundred byes of code tops.

Secondly,  it is a really really good idea for the bootloader to be the first piece of code you write on a new product, and where possible you should use it as the default way to upload code during development. That way it gets plenty of testing and any issues will quickly become apparent.
Doing the bootloader at the last minute is asking for trouble as you won't have time to test it. 

[mikeselectricstuff]

Boot loaders should ALWAYS do a CRC on the main code (and itself)

No point checking itself - flash doesn't fail, and there's nothing it could do about it, and if its own code is corrupt, all bets are off.
One important rule when writing a bootloader is that it should do the bare minimum required to achive its function,  to minimise the risk of bugs,and not waste app code space. Anything that can be done on the host side should be done there.

The boot loader can write it's own CRC after a successful firmware upload, but the boot loader/PC should also do CRC checking on the code during uploading.

There is no sense in the BL generating the check. Again, unnecessary code. It would also allow bad code (e.g. for the wrong product) to be marked as good. It is up to the host software to determine that it is sending valid code. However in the case of the same host SW being used for multiple products, there should be some way to confirm that code for the correct product is being loaded - e.g. the bootloader returns a product type, which the host code matches to a version word embedded in the code file before allowing the upload

There is also minimal benefit in doing checking during upload, unless the upload data path is inherently subject to errors (e.g. wireless,NFC, optical etc.), in which case it will need to use a 2-way handshake with the host code to ensure data integrity

[rsjsouza]

At the very least, MB should have put a "How to program firmware.txt" file on the github page - it is not reasonable to expect people to know that right-click save-as doesn't work as expected..

In the past I even had to hear things like: "if a customer does not know how to use [insert tool/language/OS], then they are too stupid to use our product".

I spend hours and hours of my work creating bullet-proof instructions for users (to the point of "click OK to continue" or "copy and paste the command below to the linux terminal"), and despite obvious and measurable results (a flood of questions regarding specific features or procedures, for example), every single time this effort needs to be justified across development teams.

This costs time and money, and sometimes the development money goes towards new features (measurable) instead of product robustness and documentation (not easily measurable).

[madires]

With all due respect, the fact that AVR Studio wouldn't accept it should have made you immediately look at the file contents. but instead, you just went ranting about this damn software, as you tend to do.

No, I went online and checked to see if anyone else had the same issue, they did, and that lead me into another direction with using avrdude.

It's amazing how we adapt to the internet. In the past most went to the book shelf to look up something they didn't know. With the internet we google, it's so convenient. An now we even google first before thinking at all :-)

[amyk]

I think the blame with this lies on Github for linking to HTML files with a .HEX extension.

If I right-click and Save As, I get "Type: HTML document" in the dialog and it gets saved with the extension ".hex.htm" AND an HTML icon, which would just show as ".hex" if you had file extensions hidden (another horribly retarded design decision by MS, I always have extensions displayed precisely to avoid this and more severe issues) but then, presumably the .hex extension on a true hex file would be hidden too and it would have a different icon?