Author Topic: Adventures in AVR ISP Programming  (Read 14141 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblog

  • Administrator
  • *****
  • Posts: 28372
  • Country: au
    • EEVblog
Adventures in AVR ISP Programming
« on: February 18, 2017, 12:09:34 pm »
Dave battles the Atmel/Microchip AVR ISP Mk2 programmer with AVRdude in order to program an ATMEGA328 and get his uRAD radiation monitor working again. Can he do it?
http://www.uradmonitor.com

 
The following users thanked this post: radhoo

Offline VK3DRB

  • Super Contributor
  • ***
  • Posts: 1424
  • Country: au
Re: Adventures in AVR ISP Programming
« Reply #1 on: February 18, 2017, 01:15:12 pm »
I agree, the AVR Studio is a debacle with installation.

If you don't want very annoying vague error messages popping up during installation, you cannot have the AVR studio on any other drive than drive C. This bug has been around for yonks and the programmers at Atmel have not seen it fit to fix it.

Also, don't bother with WinAVR. It is olde school. The last release was in 2010. I had problems with WinAVR on Windows 10 and Atmel Studio 7. Atmel Studio 7 comes with a native C compiler built in and from my experience, it is "pin compatible" with WinAVR and it works a treat. I recompiled a major WinAVR project with the native C one and no error messages at all. No adjustments needed. Good one, Atmel.

But a real gripe is the PFC ribbon cable Atmel has on their JTAGICE MKII programmer. What pot smoker came up with that idea? They tear and break with ease. Atmel charge a king's ransom to replace the cable - around $40 USD. However I found a MUCH cheaper pin compatible replacement for around $3.50 USD. They are almost impossible to find, but you can get them here...

Longer cable (about 8")...
http://au.element14.com/wurth-elektronik/687730200002/cable-ffc-rev-0-5mm-200mm-30way/dp/1908559 (Only 3 left, sorry, after I bought 3 others two days ago)

Shorter cable (about 6")...
http://au.element14.com/wurth-elektronik/687730152002/ffc-cable-30pos-152mm-60v-white/dp/2520275 (Plenty in stock)

You won't find them as cheap anywhere else.


 

Offline Muttley Snickers

  • Supporter
  • ****
  • Posts: 1893
  • Country: au
Re: Adventures in AVR ISP Programming
« Reply #2 on: February 18, 2017, 01:30:27 pm »
I agree, the AVR Studio is a debacle with installation.
+1

Slightly old school, I found this little beauty below at the local recycle center a while back and couldn’t possibly leave it there, not at $20 anyway with the box half filled with dozens of various unused Atmels still in the wrappers, a good reminder that I’m probably due for an updated version, this thread should be a good guide.
 

Offline HwAoRrDk

  • Frequent Contributor
  • **
  • Posts: 568
  • Country: gb
Re: Adventures in AVR ISP Programming
« Reply #3 on: February 18, 2017, 01:48:13 pm »
Never used avrdude before? Now that's not true, he has! ;) But he probably didn't realise it. The Arduino IDE uses avrdude to program boards. And so, Dave didn't need to bother with installing WinAVR, as he could have just used the copy of avrdude that the Arduino IDE uses - assuming he still had it installed, of course.

Although one thing to note is that if he had gone ahead and finished installing Atmel Studio to start with, it would have installed the 'Jungo' driver for his ISP MkII, which avrdude doesn't work with. It only works when the programmer is using the libusb driver. Fortunately, Atmel Studio 7 also plays nicely with libusb-driven programmers. :)
 

Offline sleemanj

  • Super Contributor
  • ***
  • Posts: 2280
  • Country: nz
  • Professional tightwad.
    • The electronics hobby components I sell.
Re: Adventures in AVR ISP Programming
« Reply #4 on: February 18, 2017, 02:18:00 pm »
Indeed, the Arduino IDE even has an up to date version of the avr toolchain including avrdude these days, instead of the fairly ancient version it was stuck with for a while.

Even if you don't ever open the Arduino IDE, it makes for a nice simple install of a working toolchain.
~~~
EEVBlog Members - get yourself 10% discount off all my electronic components for sale just use the Buy Direct links and use Coupon Code "eevblog" during checkout.  Shipping from New Zealand, international orders welcome :-)
 

Online TheSteve

  • Supporter
  • ****
  • Posts: 2849
  • Country: ca
  • GHz or bust
Re: Adventures in AVR ISP Programming
« Reply #5 on: February 18, 2017, 04:08:15 pm »
Newer AVR Studio is so terrible. They should be ashamed.
VE7FM
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 8032
  • Country: us
Re: Adventures in AVR ISP Programming
« Reply #6 on: February 18, 2017, 07:07:05 pm »
I agree, the AVR Studio is a debacle with installation.
+1

Slightly old school, I found this little beauty below at the local recycle center a while back and couldn’t possibly leave it there, not at $20 anyway with the box half filled with dozens of various unused Atmels still in the wrappers, a good reminder that I’m probably due for an updated version, this thread should be a good guide.

The STK500 is great, I bought mine around 17 years ago and still use it, it's been rock solid. I forget what version of AVR Studio I use but it's an older one. I also use Bascom AVR which can talk directly to the STK.
 

Offline radhoo

  • Contributor
  • Posts: 31
  • Country: ro
    • My technology blog
Re: Adventures in AVR ISP Programming
« Reply #7 on: February 18, 2017, 08:11:59 pm »
Newer AVR Studio is so terrible. They should be ashamed.
At its core, this is more of a Microsoft issue then Atmel's. Especially for the latter, I have nothing but my appreciation, for all the great things they created (that includes Arduino with everything that resulted from it).

Blog :: My Youtube :: uRADMonitor :: "Build something that matters!"
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11841
  • Country: gb
    • Mike's Electric Stuff
Re: Adventures in AVR ISP Programming
« Reply #8 on: February 18, 2017, 08:47:38 pm »
Newer AVR Studio is so terrible. They should be ashamed.
+1
Especially if all you want to do is program a part.
Last time I had to do it, ISTR they'd stopped including the command-line stk500.exe standalone programmer, and the new studio loads firmware into AVRISP that the old STK500.exe won't talk to.

Ever since the very earliest days. Atmel just didn't get what was needed for device programming, like including fuse settings in the hex file. And being able to set fuses to disable the programming interface on a device in about 3 different ways. And requiring a clock for programming,. so your programmer has to either program slowly or know what the clock is, or program the clock fuses before speeding up to program the main flash.

And did they ever get round to including a disaasembler view in Studio? V4 is the most recent I've used serously and that didn't even have a memory view!
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11841
  • Country: gb
    • Mike's Electric Stuff
Re: Adventures in AVR ISP Programming
« Reply #9 on: February 18, 2017, 08:56:50 pm »
..and the bigger question is why didn't the urad monitor people bother to include a bootloader to allow easy firmware updates without having to dick about with hardware programmers?
If you're doing something that will be used by lots of people all over the place surely that's a total no-brainer.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline radhoo

  • Contributor
  • Posts: 31
  • Country: ro
    • My technology blog
Re: Adventures in AVR ISP Programming
« Reply #10 on: February 18, 2017, 09:13:42 pm »
..and the bigger question is why didn't the urad monitor people bother to include a bootloader to allow easy firmware updates without having to dick about with hardware programmers?
If you're doing something that will be used by lots of people all over the place surely that's a total no-brainer.
Because everything takes a lot of time, and for the size of this project there were other priorities.
But good news, not only a boot-loader, but a full OTA firmware upgrade system is one of the upcoming features  :-+. One step at a time.

Blog :: My Youtube :: uRADMonitor :: "Build something that matters!"
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11841
  • Country: gb
    • Mike's Electric Stuff
Re: Adventures in AVR ISP Programming
« Reply #11 on: February 18, 2017, 09:22:30 pm »
..and the bigger question is why didn't the urad monitor people bother to include a bootloader to allow easy firmware updates without having to dick about with hardware programmers?
If you're doing something that will be used by lots of people all over the place surely that's a total no-brainer.
Because everything takes a lot of time, and for the size of this project there were other priorities.
But good news, not only a boot-loader, but a full OTA firmware upgrade system is one of the upcoming features  :-+. One step at a time.
A bootloader shouldn't take more than a day to do - for something designed for wide distribution like this, it should be pretty much the first thing that gets done, as it will easily save way more time in the long term.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline radhoo

  • Contributor
  • Posts: 31
  • Country: ro
    • My technology blog
Re: Adventures in AVR ISP Programming
« Reply #12 on: February 18, 2017, 09:57:17 pm »
A bootloader shouldn't take more than a day to do - for something designed for wide distribution like this, it should be pretty much the first thing that gets done, as it will easily save way more time in the long term.
Years ago, when I started with software development, I had the same drive: "yes, it only takes one day". This almost became the answer for any task, no matter of the complexity. Then I learned there is a big difference between "prototype" and "production", between "proof of concept" and "stable". Then the bugs, which doubled everything beyond initial estimation. I learned that to stay committed to a direction and actually finish something beyond a simple prototype (putting to production for instance), there needs to be a balance in the decisions: some features go first, others are part of future updates.
IMO, first thing was to get the system going and do its job, and it took a lot to make that happen (hardware, suppliers, manufacturing, firmware, server infrastructure, API access, frontend, bugs, new features, and then the human part: emails, support).

But, I already said this feature is on the list, and will be done when times allows it. Some hardware changes are needed too, like adding a FT232  for USB upgrades and an EEPROM for OTA upgrades. The USB thing triggers a change to the DC connector used, and I'm not happy with that.

Blog :: My Youtube :: uRADMonitor :: "Build something that matters!"
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3075
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Adventures in AVR ISP Programming
« Reply #13 on: February 19, 2017, 02:32:31 am »
A bootloader shouldn't take more than a day to do - for something designed for wide distribution like this, it should be pretty much the first thing that gets done, as it will easily save way more time in the long term.
Mike, of all the people you're the last one I was expecting such a comment from.

You are right, it takes a day or two... To get it working on your desk with the debugger hooked in.
The real world expands beyond your desk though, and challenges your software with various obstacles. To name an example: users.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11841
  • Country: gb
    • Mike's Electric Stuff
Re: Adventures in AVR ISP Programming
« Reply #14 on: February 19, 2017, 03:12:59 am »
A bootloader shouldn't take more than a day to do - for something designed for wide distribution like this, it should be pretty much the first thing that gets done, as it will easily save way more time in the long term.
Mike, of all the people you're the last one I was expecting such a comment from.

You are right, it takes a day or two... To get it working on your desk with the debugger hooked in.
The real world expands beyond your desk though, and challenges your software with various obstacles. To name an example: users.
Which is exactly why the first thing you should do is the bootloader, and use it as the method for firmware loading during development as much as possible. That way it gets well tested.
 Once you have that done reliably, it doesn't matter how flaky the rest of the system is as you always have a way to fix it easily in the field later.
 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline radhoo

  • Contributor
  • Posts: 31
  • Country: ro
    • My technology blog
Re: Adventures in AVR ISP Programming
« Reply #15 on: February 19, 2017, 03:19:45 am »
The firmware update, at least on these things, is a feature, not a must have. There is no need for updates in the field. The units are shipped preloaded with the stock firmware, and only the more technical users are approaching the upgrade subject for the new features that are implemented. And they know how to do it, regardless of using an USB cable, or an ISP cable.

But generally speaking, having easier tools helps, and I think I say it the third time that I agree with mike's input. It's just that other things went first.

Blog :: My Youtube :: uRADMonitor :: "Build something that matters!"
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 8032
  • Country: us
Re: Adventures in AVR ISP Programming
« Reply #16 on: February 19, 2017, 07:54:24 am »
Maybe I'm in the minority here but I never cared much for bootloaders, more trouble than they're worth with an open project. Just give me a standard 6 or 10 pin programming header so I can plug in my STK500 or USBASP and I can program the device in about 10 seconds, no screwing around with serial cables and bootloaders.

Some valid points above though, as much as I like AVR micros, the requirement of a clock for programming is ridiculous, get the clock settings wrong and you can brick the chip and require HV programming which most hardware doesn't support. The programming interface should get a clock from the programmer talking to it and bypass all settings.
 

Offline radhoo

  • Contributor
  • Posts: 31
  • Country: ro
    • My technology blog
Re: Adventures in AVR ISP Programming
« Reply #17 on: February 19, 2017, 07:58:16 am »
Just give me a standard 6 or 10 pin programming header so I can plug in my STK500 or USBASP and I can program the device in about 10 seconds, no screwing around with serial cables and bootloaders.
You would set a new record, James, as if I recall, the fastest update on one of the units so far was 4 minutes. Because the aluminium enclosure also has some screws :-DD
What I want the bootloader for is the OTA updates. To be able to push the new firmware from the server directly.
That might be tricky over the LoraWAN connections, but will go just fine on Ethernet/Wifi/GSM , these 4 being the communication methods used so far.

Blog :: My Youtube :: uRADMonitor :: "Build something that matters!"
 

Offline james_s

  • Super Contributor
  • ***
  • Posts: 8032
  • Country: us
Re: Adventures in AVR ISP Programming
« Reply #18 on: February 19, 2017, 08:05:42 am »
Well, yeah if the firmware needs to be updated regularly then a bootloader is nice. I rarely update things once they work though.
 

Offline radhoo

  • Contributor
  • Posts: 31
  • Country: ro
    • My technology blog
Re: Adventures in AVR ISP Programming
« Reply #19 on: February 19, 2017, 08:09:56 am »
Well, yeah if the firmware needs to be updated regularly then a bootloader is nice. I rarely update things once they work though.
Well, it's the same here: Once the device is shipped with its stock firmware, can go like that forever. But the feature is in the (big) TODO list and I'll do it when I get the chance.

Blog :: My Youtube :: uRADMonitor :: "Build something that matters!"
 

Offline fki82

  • Contributor
  • Posts: 28
  • Country: de
Re: Adventures in AVR ISP Programming
« Reply #20 on: February 19, 2017, 08:30:06 am »
Wouldn't it be enough to just put the Arduino bootloader there?
The device may have a serial port to a PC anyway.
I think they are using AVRdude on the PC side, to do the flashing.
Add a few scripts to that and you could have a standalone firmware update tool.
 

Offline radhoo

  • Contributor
  • Posts: 31
  • Country: ro
    • My technology blog
Re: Adventures in AVR ISP Programming
« Reply #21 on: February 19, 2017, 08:33:39 am »
Yes that would work, but as said it would also require a FT232 / CH340 for the UART to USB. What I will do is to have it get its firmware via the network (OTA updates).

Blog :: My Youtube :: uRADMonitor :: "Build something that matters!"
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 11841
  • Country: gb
    • Mike's Electric Stuff
Re: Adventures in AVR ISP Programming
« Reply #22 on: February 19, 2017, 09:00:02 am »
Maybe I'm in the minority here but I never cared much for bootloaders, more trouble than they're worth with an open project. Just give me a standard 6 or 10 pin programming header so I can plug in my STK500 or USBASP and I can program the device in about 10 seconds, no screwing around with serial cables and bootloaders.
Depends on your target market. Dave's vid is a classic example - 10 seconds to program, after a couple of hours dicking about to get a programmer to work.
 Bootloader doesn't necessarily needs a serial cable - the whole point is that the device can use whatever interface is available in the product. If it interfaces to anything you can get a file to, you can get firmware onto it.
But a serial cable is probably more widely available than a programmer for a specific micro family, and there are ways to write a serial loader that doesn't need specific host software - just throw a serial file at the device with generic terminal software.
Bunnie also showed a neat solution using audio form a web browser.
 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline G0HZU

  • Super Contributor
  • ***
  • Posts: 2576
  • Country: gb
Re: Adventures in AVR ISP Programming
« Reply #23 on: February 19, 2017, 09:03:15 am »
Quote
The STK500 is great, I bought mine around 17 years ago and still use it, it's been rock solid. I forget what version of AVR Studio I use but it's an older one. I also use Bascom AVR which can talk directly to the STK.

I scored a free STK500 kit a few years ago and it has been useful a few times but I still prefer my old homemade LPT based programmer for ISP stuff. It can erase, program and verify a fairly simple program for a MEGA168 in about 2 seconds.

I got the STK500 for free at work because nobody (in the SW team) could remember what it was and so it went in the bin during a lab cleanup. I doubt any of them use Atmel AVRs as PICs seem to be the choice where I work. On the version of STK500 I have here, Atmel don't even tell you what this thing is or what it does. It doesn't even say 'STK500' or 'programmer' anywhere on the hardware. The Atmel documentation that I found for the STK500 was a bit odd and vague but I think this is normal for Atmel.
« Last Edit: February 19, 2017, 09:09:20 am by G0HZU »
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3075
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Adventures in AVR ISP Programming
« Reply #24 on: February 19, 2017, 09:39:53 am »
Long time ago I bought one of these:
http://shop.myavr.com/index.php?sp=article.sp.php&artID=200006
It's an STK500 in a stick. It served me well. Now I have an mkII, which is better because it does tpi.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf