AVR UPDI programming header - reset needed?

[HwAoRrDk]

I'm considering using one of the newer ATmega 0-series microcontrollers, which are programmed using UPDI, but I'm a bit confused by what signals are going to be needed for a programming header.

Obviously, UPDI is a one-wire protocol, so you have that as well as the usual power and ground, but what about reset?

Microchip app note AN2519 section 4.5 only shows the aforementioned three pins on the 'standard' programming header, even though it mentions reset.

If there's no reset line, how does the programmer put the chip into programming mode?

[cv007]

All mega 0's have an exclusive UPDI pin that can do nothing else. The mega 0 reset pin can be used as either a reset pin or a gpio pin, controlled by a fuse setting that defaults to gpio. So, 3 pins is basically all you need, really only 2 but most programmers want to see the power rail if its not supplying the power.

A tiny0/1 has UPDI, gpio, and reset all on one pin, also set by a fuse setting which defaults to updi. In that case when you go to something other than updi your updi programmer is required to get a 12v pulse into that pin (a specific process to follow) to override the fuse setting. Not may programmers do the 12v, so if your programmer is smart it will not let you change that fuse setting as you then lock yourself out until you can come up with the 12v override method.

If there's no reset line, how does the programmer put the chip into programming mode?

All avr0/1 datasheets have a UPDI section that explains the whole process.

[HwAoRrDk]

All mega 0's have an exclusive UPDI pin that can do nothing else.

Ah, I see. For some reason I hadn't noticed that.

So, I guess any talk of 12V/HV programming is of no relevance, because if it's a dedicated pin, there's no possibility of its functionality being changed.

All avr0/1 datasheets have a UPDI section that explains the whole process.

I saw that section but didn't read it in any detail as skimming over it seemed to be mostly about the serial protocol, but now I see there is a bit about how UPDI is enabled. Seems it is simply the programmer/debugger pulling the UPDI pin low.

Given that the UPDI pin has an internal pull-up, but on AVRs they tend to be weak (~50k, IIRC?), might it be a good idea to add an external pull-up resistor?

[cv007]

might it be a good idea to add an external pull-up resistor?

There is more to it than just a low pin. It takes some specific things going on to get the updi enabled, plus there will be nothing but updi on that pin so hard to imagine what could go on that would get updi enabled when its not wanted. I suppose if it makes you sleep better, then do it.

[MarkR42]

I don't think it's required because the UPDI can assert the chip reset signal itself when necessary. Actually it often does in the normal course of programming.

As far as I know the default is for the pin to be UPDI, I've always used it as UPDI, you don't need to connect any other pins except power to program and diagnose the chip.

[HwAoRrDk]

Here's a further question about parts such as the 0-series ATtiny that have the UPDI and reset functionality shared on a single pin.

If I want to have the pin function as reset, but also allow HV programming, what do I do if I want to have peripheral circuitry that drives the reset line?

When the programmer applies the HV 12V to the line to activate UPDI, obviously the external circuitry needs to be able to handle that higher voltage, but how?

Say for example I have the output of a 74AHCT14 inverter driving the reset line. The datasheet for it says that output clamping current is ±20mA, and that "input and output voltage ratings may be exceeded if the input and output current ratings are observed". Might a solution be as simple as putting a series resistor in-between the UPDI programming header and the inverter's output?

If I am intuiting things correctly, when the inverter is driving its output high, and 12V is applied, the resistor will drop the 7V difference, and the inverter output will see no more than 5V; when it's driving its output low, the resistor will drop the full 12V difference - right? It should be just a question of choosing an appropriate resistor value, so that under normal operation a logic-low output is below the ATtiny's reset V_IL threshold of ~1V, and during HV it doesn't pass too much current (single-digit mA) and dissipate too much power. Perhaps 3.3k will do.

[MarkR42]

So are you using the UPDI pin as a reset-input, but also using 12v for programming?

I would say use a suitable resistor, your suggest of 3.3k sounds ok but I'd probably go with 10k (more "round" figure) and it will still pass enough current to assert the reset.

Remember that the inverter chip might be trying to put out 5v and it could "pull down" your 12v to a low enough level that the attiny chip won't see the 12v signal and can't be programmed.

Is it possible to disable the output of the other chip during programming? Maybe disconnect its power?

[HwAoRrDk]

So are you using the UPDI pin as a reset-input, but also using 12v for programming?

Yes. HV programming is necessary to override the fuse setting the pin as reset input.

I would say use a suitable resistor, your suggest of 3.3k sounds ok but I'd probably go with 10k (more "round" figure) and it will still pass enough current to assert the reset.

I think 10k would be too much if the built-in pull-up resistor on the ATtiny's pin ends up being at the lower end of the range the datasheet says (20-50k). The inverter wouldn't be able to pull the voltage down below the 1V VIL threshold. I think it would need to be at most 4.7k.

Remember that the inverter chip might be trying to put out 5v and it could "pull down" your 12v to a low enough level that the attiny chip won't see the 12v signal and can't be programmed.

Hmm, I don't think that's how it would work. Won't it rather be that the 5V rail that the inverter is outputting a high level from would be in fact sink a small amount of current (limited by the series resistor)?

Is it possible to disable the output of the other chip during programming? Maybe disconnect its power?

Not really. I can't think of a way of triggering that off the very line it's interfaced with.