UPDI initialisation failed- high-voltage mode

[RenzeH]

I am a new user of Attiny1614, and I recently learned to use a USB to TTL converter with pyupdi for burning. But I don’t know why the chip always fails to respond when some DIGITAL is read. At present, three 1614 chips have been locked...

I see that there is UPDI high-voltage mode in pymcuprog that can be used, but is this right? Can't be used with USB to TTL switch?I have seen many boards with high-voltage mode, but it is not easy for me to get it.

There are DIY high-voltage mode recovery tutorials on the Internet, but none of them seem to be usable by 1614. What is more simple and specific? Is there a solution?

If someone can help me take a look at the program and tell me why the chip locks up, that would be really appreciated

[xedbg]

Hi @RenzeH , The UPDI HV activation mechanisms are only possible using PowerDebugger or PICkit4 - the procedure involves an optional power toggle, followed by applying a pulse at the correct voltage with respect to Vdd, then inserting a valid key all within timing parameters.

I suggest you look further into what you are doing to UPDI/PA0 to avoid disabling UPDI. The default is for UPDI to be enabled in SYSCFG0 fuse - how are you generating your code, and/or are you setting the SYSCFG0 fuse somehow?

[SpenceKonde]

With (some? most?) of the tinyAVR parts you can disconnect the serial adapter from the UPDI line and then briefly apply 12v to UPDI (do it through a resistor, so if you fuck up you won't let the smoke out of anything), then reconnect the serial adapter and proceed to program normally. Once you use HV override on the UPDI pin, it stays that way until power cycle.. IIRC (it's very hazy - I never personally used HV programming, and have just been throwing the boards that need HV UPDI to recover into the dogpile; neither to resurrect the half dozen or so boards I bricked with inappropriate SYSCFG0, nor for any other reason, has it ever been a higher priority than the other things on my list). A few people had briefly pressed me on it, but then they figured out this trick and lost all interest in more graceful methods.

What I've always wanted to do is to use DTR and RTS lines of a serial adapter IC, with additional hardware tacked on, for this - one of them could cut power to the target (for the PC-HV sequence needed when UPDI pin is programmed to act as GPIO), the other would control the 12v. Cheap charge pump IC to generate the 12v and a few fets would do it for the hardware; adding that onto software wouldn't be hard either (now that we aren't all stuck with avrdude); there was just never enough interest for me to take time away from other projects for this).

[xedbg]

We have no foreseeable plans to include high-voltage mode into serialUPDI.

[SpenceKonde]

I wouldn't think that you would....

My goal with SerialUPDI and Microchip's goals are, I suspect, about as different as possible.

My understanding was that you use it for some internal testing and as a demo of "look how easy this is to implement UPDI programming. With no optimization for speed needed.

Whereas I needed something that someone would choose to use over jtag2updi (which I desperately wanted to deprecate, because it was just so flaky) I had times when I couldn't get any of my three of the damned things to work on something I was trying to program, and was convinced my hardware was bad, then discovered I couldn't program anything... .and then when I went back to the first jtag2updi unit, suddenly it worked - plus SerialUPDI depends only on python., maintained by the gods on high, whereas jtag2updi (and the methods we have to upload to curiosity nano et al) rely on avrdude, which is hardly maintained at all. I wanted to use pymcuprog for the *EDBG programmers, but my python expert said there was some problem with some usb library it depended something that couldn't be installed through board manager and so we couldn't. I don't know python very well (which is kind of the point of python) and he wasn't clear on it. But if we'd had that and a python we'd have only needed a python stk500 uploader script and we could have 86'd avrdude.... and there's a library for that...

@RenzeH I will probably try something like that early next year - I think they'll be as surge of demand for them among hobby types when the 14-pin DD's become available (that seems to be the one everyone is talking about. I think the 20 is more interesting, but the SOIC-20 is a gigantic brick. while the QFN-20 is a QFN and people fear soldering them at home because they don't know about hotplates

[xedbg]

@SpenceKonde - you are not far wrong... but pymcuprog has become more of a utility than just "for testing". We use it for example in provisioning of iot boards to load bridge firmware seamlessly, and will no doubt find more applications. In reality I could not afford to maintain pyupdi outside of pymcuprog and ensure the same quality (pyupdi was never really formally tested). So it was either bring it in, or let it die. This also means that if we (or whoever) make optimisations, then we could more easily verify them. Regarding DD - I can't share much at this point, but don't assume the UPDI implementation is identical to tiny...

[SpenceKonde]

What serial bridge and approx what speed do you see? The USB latency was accounting for like... 98% of the programming time when response signature wasn't disabled, because it couldn't send the next byte until it had gotten the response, and it had to wait a latency period for the response to be available.

The real problem that struck in terms of merging changes was that big new version of pymcuprog came out while I was working on the older codebase. And the code is sort of like a matryoshka doll. I had to thread parameters through like 7 files to get some command line parameter to where I need it at the very low level. So there are changes EVERYWHERE, and the automatic merge worked only for some situations and I didn't (and still don't) have the python skill to sort that out.

I also wound up doing hideous things like

def ld_ptr_inc16(self, words):
        """
        Load a 16-bit word value from the pointer location with pointer post-increment.
        """
        self.logger.debug("LD16 from ptr++")
        # combine REP, words with ld *ptr++
        self.updi_phy.send([constants.UPDI_PHY_SYNC, constants.UPDI_REPEAT | constants.UPDI_REPEAT_BYTE,
                            (words - 1) & 0xFF, constants.UPDI_PHY_SYNC, constants.UPDI_LD | constants.UPDI_PTR_INC |
                            constants.UPDI_DATA_16])
        return self.updi_phy.receive(words << 1)

because a single 1ms USB latency period at 345600 baud is, well, 345.6 bit periods. - 28-29 bytes!

Yeah, DD would have an additional complication requiring added simple hardware but reduced complex hardware. I'm pretty sure I know what this is.