-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a 12V version of microUPDI #3
Comments
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. |
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. |
More info on the "updated" high-voltage UDI activation: |
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? |
Updi on newer parts is not the same as the original 817 - as the freaks posting says, the documentation is severely lagging the silicon :/ |
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...
|
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?
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 |
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. |
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? |
I tried both, but neither worked for me...
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. |
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);
}
} |
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 ? |
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 :-( |
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? |
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.
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. |
I abandoned this project because I have better things to do, and it turned out to be trickier than I initially thought. |
I'm planning to make a 12V version of this programmer. This will allow users to program chips that's had their UPDI line turned into a GPIO pin.
This version will be physically larger than the non-12V version due to increased component count.
We can generate a 12V rail by attaching a diode/capacitor voltage multiplier to the 16 MHz clock output. The frequency should preferably have been lower, but the mEDBG firmware is very limited when it comes to customizability, so that's all we got.
The AVR is very picky when it comes to the 12V pulse. According to sources over at the Avrfreaks forum, the 12V pulse should be between 500 and 1000us long, before puled low for about 100 seconds. This can be accomplished with some careful MOSFET circuitry.
The text was updated successfully, but these errors were encountered: