UPDI 12V pulse not recognised on ATtiny814

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

I am attempting to make a UPDI programmer that can send the 12V pulse needed to activate UPDI when the chip is in one of the other modes (RESET or GPIO), but so far I am not having any success.

 

I have an ATtiny814 chip which I have successfully programmed using UPDI, and the last thing I managed to do was write the SYSCFG0 fuse to put the pin in RESET mode. The chip still runs the program inside it just fine, but no longer responds to UPDI on the pin.

 

Next, I've attached a circuit to generate a 12V pulse on the pin for 1msec, before the programmer talks UPDI to it. If I don't have this circuit actually attached to a chip, then the 12V pulse works just fine, followed by UPDI sending the initial BREAK and initial commands, which then eventually fails because no chip answers. All good so far. See the "UPDI-opencircuit" picture, attaached. The topmost yellow trace shows the voltage on the UPDI pin of the chip. Next in cyan is the TX output of the UART bridge which is hoping to talk UPDI, and finally in pink is the output from the 12V pulse generator. The 12V pulse reaches its full height, and the BREAK condition and subsequent UART activity is visible on the (open) pin.

 

But talking to the actual chip this all fails. The other two scope captures show the result, and also a zoomed-in portion of the 12V pulse specifically. Note how the 12V pulse generator in pink reaches a good peak of 13.6V, but the UPDI pin only gets to 8.8V. Later, when the UART tries to send its BREAK condition (the cyan trace goes low), the UPDI pin doesn't really see that as it seems to be holding the pin high itself. What appears to be happening is that when the 12V pulse is generated, it isn't strong enough to overcome whatever inside the ATtiny814 is driving that pin, because at the UPDI pin itself the pulse only reaches about 8.8V (as measured by the scope), which isn't enough to trigger the VCC*2 of the ATtiny's detector. This stops it from releasing the pin.

 

The reason the voltages sag before the 12V pulse, is that I also have my circuit interrupting the power supply to the ATtiny for 20msec beforehand, to let it do a poweron reset immediately before I try to give that 12V pulse. This happens much within the 8.8msec that the datasheet says the chip would be refrain from driving the pin on startup, if it was in GPIO mode.

So in summary - I'm not sure how I can reprogram this chip any more. I can't get a 12V pulse into it to kick it into UPDI mode any more. What am I doing wrong here?

Attachment(s): 

This topic has a solution.

Last Edited: Fri. Jun 7, 2019 - 09:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it sounds like your 12v source is not strong enough to pull the pin high, if the reset pin is in GPIO mode, the 12v pulse must be applied after power up but before the 8.8ms timer expires that releases the pin to the GPIO driver.  So you have a short window to assert the 12v pulse after applying power to the chip.  If the pin is in RESET mode, you don't have that time constraint, but how would you know if trying to talk to a chip in an unknown configuration? 

Can you post your programmer's schematic?  and a picture of your setup?

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

You programed the UPDI pin as output in your running program? Maybe that's why you get such a drop.

My advice is, put a smaller resistor between the programmer and the UPDI pin, maybe half of what you have currently, so that the voltage drop is less.

 

Then, follow this (undocumented in the datasheet) 12V programming procedure, posted by an Atmel employee: https://www.avrfreaks.net/commen...

 

That is, instead of the break signal just follow up the 12V pulse with a KEY command after less that 65 ms. I never tested this procedure, but if it works please keep us posted.

 

edit:

You know, this is a question that has been in my mind.

Let's say you programed the UPDI pin as I/O with the fuses, then your running program sets it as output low. In this case, it will not be at all easy to bring it up to 12V!

The impedance of the reset/UPDI pin is not as well characterised in the datasheet as the regular I/O pins, but from the little data that can be gathered, it seems to be about 2 kOhm for VDD = 5V.

This means, in a worst case scenario, you may need to inject 6 mA to get the pin to 12V.

 

edit #2:

I see you tried to circumvent this by doing a power on reset immediately before the programming attempt, but I don't think this is a good approach, the programmer cannot be expected to have control over the target supply in most situations, right? IMO you just have to inject whatever current it takes to get the UPDI pin to the programming voltage threshold (apparently 2x VDD).

Maybe this would involve a (probably sizeable) capacitor precharged to 12V? (I did a few calculations, a 4.7 to 10 uF cap discharging at 6 mA will drop from 12V to about 11V in 1 ms, so it should work)

 

edit #3:

I'm completely guessing, since I have no idea what kind of circuitry you have in your project.

Last Edited: Fri. Jun 7, 2019 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have attached a schematic of the programmer, annotated with three coloured ticks to show where the probes are attached.

 

ki0bk wrote:

it sounds like your 12v source is not strong enough to pull the pin high,

 

I did think that at first, but the pink trace is sitting at the output of the 12V generator and shows it does reach the full 12V swing. The voltage is dropped entirely across the 220R resistor R3.

 

Quote:
if the reset pin is in GPIO mode, the 12v pulse must be applied after power up but before the 8.8ms timer expires that releases the pin to the GPIO driver.  So you have a short window to assert the 12v pulse after applying power to the chip.

 

Indeed. That's why I gave the programmer control of the target power supply, (Q3 in attached schematic) and had it send that 12V pulse immediately after powerup. That was well within the 8.8msec.

 

Quote:
If the pin is in RESET mode, you don't have that time constraint, but how would you know if trying to talk to a chip in an unknown configuration?

 

It turns out I don't think the pin is in RESET mode but GPIO mode, because there's actually a strong driver on it. If I ground that pin, it shorts VCC and upsets the PSU driving the board. Which is odd, because I don't think my program should be touching PA0 (or any of the PORTA pins) at all.

 

Quote:
Can you post your programmer's schematic?  and a picture of your setup?

 

Programmer schematic attached. The ATtiny85 in the bottom corner is just providing timing pulses for the various transistors, and here's the source code for completeness anyhow:

 

#include "clock.h"

#include <avr/io.h>

#include <util/delay.h>

#define PB_RTS   PB0
#define PB_12V   PB1
#define PB_RESET PB2
#define PB_VTG   PB3

int main(void)
{
  clock_set_prescale(CLOCK_PRESCALE_1);

  PORTB &= ~_BV(PB_12V)|_BV(PB_RESET)|_BV(PB_VTG);
  DDRB  |=  _BV(PB_12V)|_BV(PB_RESET)|_BV(PB_VTG);

  while(1) {
    // Await RTS falling edge
    while(!(PINB & _BV(PB_RTS)))
      ;
    while(PINB & _BV(PB_RTS))
      ;

    // Power cycle
    PORTB |= _BV(PB_VTG);
    _delay_ms(40);
    PORTB &= ~_BV(PB_VTG);

    _delay_us(100);

    // RESET
    PORTB |= _BV(PB_RESET);
    _delay_us(100);
    PORTB &= ~_BV(PB_RESET);

    _delay_us(100);

    // 12V kick
    PORTB |= _BV(PB_12V);
    _delay_ms(1);
    PORTB &= ~_BV(PB_12V);
  }
}

 

Attachment(s): 

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

El Tangas wrote:

You programed the UPDI pin as output in your running program? Maybe that's why you get such a drop.

 

I don't believe I did so intentionally. The only mention of PORTA.DIR occurrs in a line:

 

#define WS2812_PIN  4
PORTA.DIRSET = _BV(WS2812_PIN);

 

Also I would imagine that PA0 defaults to being an input unless told otherwise.

 

Quote:
My advice is, put a smaller resistor between the programmer and the UPDI pin, maybe half of what you have currently, so that the voltage drop is less.

 

The resistor is already a mere 220R, with the 12V source being the output from an LTC1262 - it's capable of delivering 30mA. I've even tried it with no resistor at all, and at times it can manage to short the entire USB port the whole setup (via the CP2105 UART bridge) is connected to, such that the USB device falls off the PC and I have to replug it. Even that doesn't manage to draw the pin high enough.

 

Quote:
Then, follow this (undocumented in the datasheet) 12V programming procedure, posted by an Atmel employee: https://www.avrfreaks.net/commen...

 

That is, instead of the break signal just follow up the 12V pulse with a KEY command after less that 65 ms. I never tested this procedure, but if it works please keep us posted.

 

Trying that, but it makes no difference at the moment. Looking on my scope I can see the UART chip trying to transmit data (the cyan trace) but the UPDI pin doesn't move, being forced by the ATtiny814 to stay at VCC, so the yellow trace isn't moving because the ATtiny814 is holding it high with a strong driver. Until I get something out of that, it won't make any difference what bytes I send.

 

Quote:

edit:

You know, this is a question that has been in my mind.

Let's say you programed the UPDI pin as I/O with the fuses, then your running program sets it as output low. In this case, it will not be at all easy to bring it up to 12V!

The impedance of the reset/UPDI pin is not as well characterised in the datasheet as the regular I/O pins, but from the little data that can be gathered, it seems to be about 2 kOhm for VDD = 5V.

This means, in a worst case scenario, you may need to inject 6 mA to get the pin to 12V.

 

edit #2:

I see you tried to circumvent this by doing a power on reset immediately before the programming attempt, but I don't think this is a good approach, the programmer cannot be expected to have control over the target supply in most situations, right? IMO you just have to inject whatever current it takes to get the UPDI pin to the programming voltage threshold (apparently 2x VDD).

Maybe this would involve a (probably sizeable) capacitor precharged to 12V? (I did a few calculations, a 4.7 to 10 uF cap discharging at 6 mA will drop from 12V to about 11V in 1 ms, so it should work)

 

edit #3:

I'm completely guessing, since I have no idea what kind of circuitry you have in your project.

 

That's all sounding rather destructive in the worse case. I know in general a programmer won't have target VCC control, but in my case I know I do because I'm powering it via the programmer for this exact purpose.

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

I still think its a matter of timing, after power up it takes some milliseconds for the internal reset to be released depending on the SUT fuses, then you have a small window to pulse the reset line depending on how the pin is configured. 

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ugh. Sorry all - I have just found what the problem was. It was purely hardware.

 

In summary: how the development board is mounted on the breadboard, the pins of the "RESET" button just poke out a tiny bit from the board, just enough to have squashed them up against one of the power rail jumpers and broken the insulation, causing a short between - you guessed it - UPDI and the +5V rail. Thus explaining why the pin appears to be driven hard high.

 

I found this by removing the entire ATtiny breakout board from the breadboard to test it on its own - that actually worked. Mounting it back on the board - it breaks.

 

Now this is fixed, I shall experiment with a few other bits and pieces relating to the 12V activation of UPDI, and report back here with a conclusive summary of what does and doesn't work.

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

Glad you figured it out, when you said a 220 Ohm resistor was used I thought "What? Then how is this possible?".

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

Right then. My summary appears to be this:

 

When in UPDI mode (RSTPINCFG=1), there is no need to send the 12V pulse, though doing so doesn't upset anything.

 

When in RESET mode (RSTPINCFG=2), there is only a weak pull-up resistor internally so an external 12V pulse is able to knock the chip into UPDI mode. Once applied, the mode remains in effect indefinitely (or at least, for the few minutes I tested it). You can apply the pulse just once - manually by touching a resistor if necessary, and then talk UPDI possibly many seconds afterwards, and all works fine. Only a POR sets it back again.

 

When in GPIO mode (RSTPINCFG=0) and the pin is set as an INPUT, it effectively behaves the same as RESET mode. The 12V pulse can be applied at any time.

 

When in GPIO mode and the pin is set as an OUTPUT, the 12V pulse must be applied after a POR, which the programmer could manage by interrupting target power. If this is done, the programmer has only a short time before the pin output is applied. I wrote a program that sets the output low immediately on startup, within about 20 instructions or so. Experimenting with various settings of the SUT fuse and watching on an oscilloscope to see when the pin goes low (against the weak pullup of the UPDI programmer), I get the following timings:

 

At VCC=5V:

  SUT 64ms => 67.2ms

  SUT 8ms => 15.5ms

  SUT 1ms => 9ms

 

At VCC=3.6V:

  SUT 64ms => 70.8ms

  SUT 8ms => 16.2ms

  SUT 1ms => 10.5ms

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

Thanks for sharing the result of your testsyes

 

leonerd wrote:
When in GPIO mode and the pin is set as an OUTPUT, the 12V pulse must be applied after a POR, which the programmer could manage by interrupting target power. If this is done, the programmer has only a short time before the pin output is applied.

 

So what exactly happens if you apply the 12V pulse after that time? Can you measure the impedance of the UPDI pin when set as output? The datasheet is not very clear on that...

Last Edited: Sat. Jun 15, 2019 - 11:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice summary! However newer UPDI parts do a require that a key I clocked in within a certain time period after the 12V pulse - there is a thread on that somewhere... You probably have an older part...