In-system programming

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

I'm pretty much a rookie at using micro-controllers. I've been successful with a few projects, and program the chips (Attiny11) using the STK500 programmer with AVR Studio.
However, I usually just buy a DIP package and layout the board for a DIP because I don't know how to program an SOIC package.
I have been reading about "in-system" programming. Does this mean that I can take my system completely assembled, and attach a cable to my system and program this way?
Assuming I am correct so far, it appears that buying an ATAVRISP2 programmer does the trick. Looking at the online manual in the Atmel website for this part, it says that Vcc, Gnd, MISO, MOSI, and SCK come from the USB port and I just need to have a header on my board that brings these pins to the processor. How does this not interfere with the other devices on these pins (LEDs or sensors tied to the I/O pins)?
Can someone please help explain what I'm missing? Thanks a lot. (My next problem will be to see how I find your responses since I am new to AVRFreaks).

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

Quote:
I have been reading about "in-system" programming. Does this mean that I can take my system completely assembled, and attach a cable to my system and program this way?

You are correct!

Quote:
Assuming I am correct so far, it appears that buying an ATAVRISP2 programmer does the trick.

You are correct!

Quote:
Looking at the online manual in the Atmel website for this part, it says that Vcc, Gnd, MISO, MOSI, and SCK come from the USB port

You are NOT correct!

These pins are pins located on your brand new DIP device (which one?), the reset pin, MOSI; MISO and SCK are however controlled by avrispmk2 which connects to you computer and avr studio through USB cable.

Please read instructions for using ISP in the AVR tools user guide found under HEEELP in AVR studio. This help file shows you the pinout of the 6pin header. For MOSI, MISO, and SCK these should be connected directly to corresponding mcu pin. Devices in your design using these pins should be connected to mcu using a serial resistor. Also, remember that Reset pullup must be atleast 4k7 or more.

Quote:
(My next problem will be to see how I find your responses since I am new to AVRFreaks).

Could be solved if you could be setting up your forum profile to send you an email each time a replay occoures by simply by setting "Always notify me of replies:" to yes.

But, why should I care writing this,(?) you'l never reach this forum again anyway ;)

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

Thanks a lot for your reply. So I guess I will buy the AVRISP2 device since it will allow me to solder down the processor and re-program until it works like I need it to. I still don't understand about the conflict between the I/O pins. I understand that I can only source or sink a limited amount of current. So for instance, if I was driving a small motor, I would use a transistor or other motor driver so that I am only sinking a few mA or less. But if my programmer is supplying power to Vcc and is also toggling this pin, then won't it toggle the signal that turns on the motor just like the processor would if it was toggling this pin? Thanks for your time.
John

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

> So I guess I will buy the AVRISP2 device since it will allow me to
> solder down the processor and re-program until it works like I need
> it to.

Just be aware of some possible pitfalls: while the ISP interface
(officially) cannot disable itself by disabling the SPEN fuse, for
certain AVRs, you can still effectively disable the ISP functionality
anyway, thus leaving you with a board that cannot be reprogrammed
anymore without unsoldering the controller. This affects all those
smaller AVRs that can be debugged using the debugWIRE protocol,
because debugWIRE uses the /RESET line to communicate the debugging
protocol, so /RESET is no longer available for in-system programming.
Also, on some AVRs, there is a RSTDISABL fuse that allows turning the
/RESET pin into a normal GPIO pin: if you do this, you cannot use ISP
anymore either.

Both these are controlled via fuse bits (some kind of EEPROM cell that
cannot be modified by the controller firmware itself, only by the
programming interface), so it's just that you need to be careful with
modifying the fuse bits.

> I still don't understand about the conflict between the I/O pins.

It can happen if your target circuitry also uses the MOSI, MISO and
SCK pins. The ISP adapter wants to drive MOSI and SCK actively, so if
you've got something connected on the target board (*not* the AVR
itself, but something outside) that is also going to actively drive
these, you've got a conflict.

If you cannot avoid that situation, it's best to have the external
circuitry on those pins going tri-state when monitoring the /RESET
line being active. As the first step when programming, the ISP
adapter drives /RESET low (so the AVR will tri-state all its pins), so
if everything you might connect to the ISP interface of the AVR also
tri-states in this situation, this will completely leave the interface
to the ISP programmer.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Okay thanks. I think I understand. One more thing. It's not completely clear in the STK500 user guide, but it sounds like I can program my system with what comes in this kit without having to buy additional equipment such as the AVRISP. Is this correct? In other words, instead of putting the chip in one of the sockets, I just run the header cable from the STK500 board over to my circuit per their instructions and program away?

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

> It's not completely clear in the STK500 user guide, but it sounds
> like I can program my system with what comes in this kit without
> having to buy additional equipment such as the AVRISP. Is this
> correct?

Yes, that's correct.

If you got an STK500, you can always reprogram any mis-fused chip
using high-voltage programming inside the STK500 (but that's usually
not possible while the AVR resides in its own target board).

> In other words, instead of putting the chip in one of the sockets, I
> just run the header cable from the STK500 board over to my circuit
> per their instructions and program away?

Exactly that way. The 6-pin ISP jumper cable that comes with the
STK500 is only a few centimeters, but it should be possible to prepare
a custom cable of 20...30 cm without problems (please turn that into
thumbs, inches, feet or whatever you prefer ;-).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Great thanks a lot for your help. I should be all set.
John

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

I finally got my card in and successfully programmed using ISP, and after all the detail that you sent, I screwed up and used the rst/PB5 pin in my design as PB5. Therefore I needed to program the RSTDisable fuse on my SOIC Tiny13. It worked the first time, but now I can't re-program.

You said in your response:

Quote:
Also, on some AVRs, there is a RSTDISABL fuse that allows turning the
/RESET pin into a normal GPIO pin: if you do this, you cannot use ISP
anymore either.

Now I fully understand the meaning. So in a nutshell, does this mean if you require in-system programming on an 8 pin device (and require the ability to program more than once), that you only have 5 I/O available instead of 6? And there's no way around this?

Thanks,
John

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

The idea of RSTDISBL and using the _reset line as an IO is that you do all the development of your application with multiple low voltage ISP cycles but only once you are ready to finalise the app do you ISP the code into it and THEN change the RSTDISBL fuse.

If you need to get back from RSTDISBL then you need to use the HVP from something like an STK500 to get back in contact with the chip. You could use this to do repeated ISP/text cycles if you like but you'll need to change the fuse each time after you have programmed the code.

I agree the help in AVR Studio for the STK500 (which is more up to date than the STK500's printed manual) is less than forthcoming about exactly how you wire things up for off board external HVP serial programming but a combination of the info it gives and the Tiny13 datasheet should give you all the info you need.

Cliff

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

Thanks Cliff. Since my application requires the use of the PB5, I can't iteratively program the part/debug/ re-program until the development is complete, THEN program the fuse. I need to program the fuse to check out the functionality, then un-program the fuse to try out the next round of code.

You mention:

Quote:
...about exactly how you wire things up for off board external HVP serial programming

Does this mean YES, I can absolutely do high voltage ISP programming? I just need to figure out how?

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

Oh yes the STK500 (as the Studio help says) can HVP all the AVR devices. The stumbling block is that it explains how to do it when the AVR is plugged into a socket on the STK500 but is a bit vague as to which signals you need to route to where if you want to do it to an AVR/board that is separate from the STK500

Cliff

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

Thanks Cliff. If the STK500 can program in serial high voltage mode (which I've done with tiny11s), then it sure seems like you must be able to pull the signals off the board. I'll try to dig into the schematics for the stk500 board to see if I can make sense of it.
Thanks again,
John