Studio 6 & 7 programming issues

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am having programmer problems with Studio 6.2. I repeatedly get 'busy' status after a programming attempt. I have been having this issue with programmers ever since version 4. I have used XP, Win10, and Vista pro as platforms, and Atmel AVR-ISP MK2,  Dragon, and the Olimex AVR_ISP MK2.  Like others I must exit and restart Studio (a 4 minute time sink repeated many times in the course of debugging) in order to do a new programming session. And yes, you must carefully match the device, and if using SPI make sure the clock is not too fast. This situation is akin to giving someone a free Ferrari, but to start it you will need to remove all 12 spark plugs and prime the cylinders, after which it may or may not start. Is there any workaround? I have installed Studio 7 on a different computer (ASUS laptop with WIN10), but that seems even worse, it can't find either the Dragon or the Olimex AVRISP. How can such wonderful micros, and an otherwise excellent toolchain, suffer from such an obvious problem? Design the hardware, lay out the board, write the code, get to delivery date and...oops, can't program the processor- help!!

 

Harry

ps I originally posted this in an old thread, no response

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If nothing else forget Studio and use avrdude.exe to do the programming (can be setup to be triggered within Studio anyway - so it still "feels" part of it).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I am now trying to figure out how to use avrdude- is it part of the winavr package or do you need to download/install separately?

 

Could this be a problem with the reset line? Does it need a 10K pull-up? Until I disabled the reset (uncheck HIGH.RSTDISBL in the fuse programming panel) all of the I/O was low (including the ~reset line), holding the chip in reset (I think). I also added a 10K pullup to the reset, after which I believe I did a successful programming session.

 

it's probably moot, but this whole issue is very strange. I successfully programmed the ATTINY261A (tssop on the target board) two days ago, using Studio 6.2/Dragon, and home-made adaptors to use the nifty 'plug of nails' programming header (target is very space limited). Then the next day- total fail. I am going to do some last-ditch tests today to see if I can use a squid cable to program the DIP version in a solderless breadboard (I was able to do this OK last week). If only there was a magic bullet to make this  tool chain as reliable as it was in days past...

 

Thanks for the fast response and your long history of assistance with us digitally challenged!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hsieber wrote:
is it part of the winavr package
For the older devices you mentioned the out of date one in WinAVR should do just fine.
hsieber wrote:
(uncheck HIGH.RSTDISBL in the fuse programming panel
Be VERY careful with that - as soon as you change RSTDISBL you will not be able to reprogram an AVR again (well not without special tools).

 

If you have activated RSTDISBL and if you don't have access to a high voltage programmer it may be time to buy some new AVRs

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Live and Learn- looks like my prototype will receive no updates. At least it is running the older version. I should have been more careful, I had a similar problem years ago with the SS pin (SPI), in that case I had to disable it since I was trying to use that pin as an input. I guess if I get desperate I can remove and re-solder a new ATtiny, fortunately I have a hot air gun, and the part is only 20 pins instead of a massive BGA!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Follow up- Dragon/As6.2  works fine with a DIP version of the part. Maybe it was the disabled reset all along. Could be worse, just bricked one unit but I have to re-assemble it on the board.

One other question re Dragon and AVR ISP- I think I read somewhere that you need to disconnect the target before the USB- true? I usually remember to do this but occasionally I might forget, will this damage the programmer or are they protected?

Thanks

H