Create a 12V version of microUPDI about microupdi HOT 19 CLOSED

I abandoned this project because I have better things to do, and it turned out to be trickier than I initially thought.

from microupdi.

Here's what I've come up with so far. The pulse generator hasn't been tested on an actual ATtiny yet, but I will do that very soon. @SpenceKonde how long did you have to keep the UPDI line low after the 12V pulse? I also want to keep @WestfW in the loop since he is actively working on Optiboot support for this chip family.

from microupdi.

Seems like a lot of stages in the voltage multiplier. I got nearly 15 V from an Arduino 50% PWM output, using of a total of 4 diodes with:

from microupdi.

Seems like a lot of stages in the voltage multiplier.

I know. I initially was planning to use only four diodes, but I only got a 10V output when driving the multiplier with 5V. With six diodes I got a voltage close to 15V. It's then clamped by a 12V zener.

I've done some more tests on my ATtiny817 Xplained mini. Seems like it doesn't matter if the UPDI line is pulled low or left high-Z after the 12V pulse have been injected. This means we can simplify the pulse generator design a lot.

However, the Q1A MOSFET should probably be driven directly by a 74LVC1G125, since this buffer has a push-pull output that will prevent the output from having a slope due to the capacitor discharge.

from microupdi.

More info on the "updated" high-voltage UDI activation:
https://www.avrfreaks.net/comment/2616176#comment-2616176
(Cross-posting from freaks.)

from microupdi.

[from Avrfreaks] If a KEY is not received within 65ms the device will continue operation as normal reset, and the pin will go back to it's non-UPDI configuration.

There doesn't seem to be a 65 ms timeout, at least not on the ATtiny817. The microcontroller is still running its program after the 12V pulse, but I am able to communicate with it over the UPDI interface, meaning that the GPIO/RST pin is temporarily converted to the UDPI pin until the next power cycle. I also found some good information in chapter 33.3.2.2 in the ATtiny417/817/1617/3217 datasheet.

Same result when pulling the line down to ground or leaving it high-Z after the 12V pulse. @mraardvark have you tried reviving a tiny0/tiny1 chip with a 12V pulse?

from microupdi.

Updi on newer parts is not the same as the original 817 - as the freaks posting says, the documentation is severely lagging the silicon :/
A 'new' 3217 definitely just resets when given a blind 12v spike. You should probably broaden your sample collection before going out on this limb...
(I guess the 817s mounted on the minis are all 'old')

from microupdi.

Did you see the part in the datasheets (416, 3217) how the 12V "enable updi sequence" is permanent till the next power cycle? It's not clear how far into the sequence you have to get for this to be the case...

When enabled by 12V, only a POR will disable the UPDI configuration on the RESET pin, and restore the default setting. If issuing a UPDI disable command through the UPDIDIS bit in UPDI.CTRLB, the UPDI will be reset and the clock request will be canceled, but the RESET pin will remain in UPDI configuration.

from microupdi.

I just finished working with this for the evening. It's super easy to recover an ATtiny817. However, some ATtinys seems to have much more strict rules when it comes to timing. I turned the UPDI line into a GPIO on at ATtiny1616, and I have not been able to recover it by manually applying 12V, or using a pulse generator. At this point, I don't know how I can recover it. I tried to time the 12V pulse as best as I could (using a scope to monitor the UPDI line), but I always got a 0x02 or 0x04 error from Atmel Studio.

Does anybody know if someone has been able to reliably recover "new tiny-1" chips, such as my ATtiny1616? If so, I'm interested to know what hardware they use. Maybe we'll have to use a dedicated microcontroller to control the 12V pulse and inject the KEY at the exact same time?

When enabled by 12V, only a POR will disable the UPDI configuration on the RESET pin, and restore the default setting. If issuing a UPDI disable command through the UPDIDIS bit in UPDI.CTRLB, the UPDI will be reset and the clock request will be canceled, but the RESET pin will remain in UPDI configuration.

My ATtiny817 behave this way. However, as @mraardvark pointed out in an earlier post, the "new" 12V interface is different.

Bottom line: The new 12V UPDI interface is a pain in the ass. I'm running out of hardware my programmer is able to communicate with ☹️

from microupdi.

Hm, it was a 1616 that I unbricked with the 500us 12v pulse followed by pulling the line low, then issuing normal updi programming a few seconds later. It did not work when the line was returned to 5v instead of 0v after the 12v pulse, though.

from microupdi.

On the 'old' 817 an ESD event on the UPDI line when used as GPIO would potentially enable UPDI and leave the application stranded without that GPIO. In an industrial product that would not be acceptable, would it?

from microupdi.

Hm, it was a 1616 that I unbricked with the 500us 12v pulse followed by pulling the line low, then issuing normal updi programming a few seconds later. It did not work when the line was returned to 5v instead of 0v after the 12v pulse, though.

I tried both, but neither worked for me...

On the 'old' 817 an ESD event on the UPDI line when used as GPIO would potentially enable UPDI and leave the application stranded without that GPIO. In an industrial product that would not be acceptable, would it?

That's true. But it makes it way more difficult for amateurs like me to enter programming mode again. I don't know the UPDI protocol very well, but maybe we could a small micro such as ATtiny202/402 to send the KEY after the 12V pulse is injected? I will assume the target won't time out after the key is received; am I right?

If so, we could make a pulse generator + "key injector" based around a voltage multiplier (to generate 12V) and a small microcontroller. By using a tiny0/tiny1 we can easily reprogram it by connecting its UPDI line to the mEDBG chip using a jumper.

from microupdi.

I've been able to compile a stripped-down version of JTAG2UPDI that can run on an ATtiny13. The JTAG2UPDI code isn't compatible with the new tiny0/tiny1 series, so I decided to use an older AVR instead. I could use an ATtiny25, but the ATtiny13 is cheaper and has enough memory for this application.

The downside with using an older AVR is that we can't use the ATmega32u4 running mEDBG firmware to program the ATtiny. The ATtiny13 is also slightly more expensive than ATtiny202.

The ATtiny13 can be driven from a 16 MHz clock output from the ATmega32u4, or from its internal 9.6 MHz oscillators (if it turns out to be accurate enough). The program flow will look something like this:

while(1) 
{
  // Button pressed
  if((PINB & _BV(PB2)) == 0)
  {
    // Poor mans debounce
    while((PINB & _BV(PB2)) == 0)
      _delay_ms(250);

    // Inject 12V pulse
    PORTB |= _BV(PB4);
    _delay_us(650);
    PORTB &= ~_BV(PB4);

    // Inject NVMPROG key
    JTAG2::enter_progmode();

    // Prevent double clicks
    _delay_ms(2000);
  }
}

from microupdi.

Here's something I'd like to make a prototype of. It's based on the JTAG2UPDI project but will send a 12V pulse followed by an NVMPROG key to enable the reset line. The target can be powered from either 5 or 3.3V. By switching the MODE switch you can use the programmer as a regular USB to serial adapter with a DTR/RTS like for Optiboot auto-reset. The board itself measures 24x44mm.

Thoughts @SpenceKonde ?

from microupdi.

I am hoping to see a working 12V UPDI programmer out of Microchip before I think too much about implementing one myself. Apparently datasheets are vague, newer chips may behave differently that older chips, and ... nothing does it yet :-(

from microupdi.

I am hoping to see a working 12V UPDI programmer out of Microchip before I think too much about implementing one myself. Apparently datasheets are vague, newer chips may behave differently than older chips, and ... nothing does it yet :-(

The only programmer I'm aware of that supposedly supports 12V is the power debugger. What I already know is that "old" chips (like the one on my 817 Xplained Mini) only need a 12V pulse, while newer chips (like my 1616 Xplained Nano) need the NVMPROG key, followed by a reset command.

But I don't see why the board above shouldn't work apart from potential electric errors?

from microupdi.

Here's the schematic for it BTW:

EDIT: Oh, R7 should be an order of magnitude higher; 100k.

from microupdi.

I don't see 3.3V/5V for RTS/DTR on the UPDI connector?
Is the analog multiplexer fast enough for the serial data rates people expect these days?

from microupdi.

I don't see 3.3V/5V for RTS/DTR on the UPDI connector?

That's something I forgot to add. Will look into this. BTW would it even be a problem to have a 5V DTR pulse on a 3.3V powered target? The RST/UPDI pin does not have the same protection diodes as other pins do, but it shouldn't cause damage or accidentally trigger programming mode on "older" Xtinys, since the voltage is way lower than VCC/2? It's also worth noting that the multiplexer has ~150 ohms of internal resistance that will limit a potential current spike.

Is the analog multiplexer fast enough for the serial data rates people expect these days?

It has a rated bandwidth of 17 MHz. Should be plenty for your average 115200 stuff. I chose this because I literally have a pile of them.

EDIT: Another "bug" is that IC1(A/B) should be powered from VCC, not directly from 3.3V. The LVC1G125 is designed to handle a 5V input when powered from 3.3V.

from microupdi.