HV mode

[jhpadjustable]

This patch adds an -hv command line argument which takes a parameter specifying the type and location of an HV switch, which is expected to safely place 12V on the UPDI line when active. -hv dtr pulses the DTR line for 10ms. -hv gpio:[-]portnum opens a GPIO port and sets it active (low if - prefix is provided, high otherwise) for 10ms, then sets it inactive and closes it. This is longer than the datasheet specifies.

Tested on an Orange Pi Zero with a hacked-together programming circuit on a Tiny402, using GPIO mode. DTR wasn't tested because I burned my last USB-serial adapter while working on this. D'oh. Python isn't my first language so style notes are accepted.

[mraardvark]

I think we should check that this works on the newer variant of the 12V implementation which requires a key insertion within a certain period of time for UPDI to be enabled.
Do you have a newer tiny available to test with?

[jhpadjustable]

Unfortunately, I won't be able to test a newer "x"tiny for a few weeks.

I assume you're referring to the new 65ms timeout to get a key in. After choosing a relatively low data rate of 19200bps, I pulled up the initiation sequence on the logic analyzer, and I see by visual inspection that the "NVMProg " key is received and acknowledged within 50ms of the end of the HV pulse, and the subsequent reset is released by 60ms. So, barring silicon bugs, if newer chips work in low-voltage mode with pyupdi, they "should" respond properly to HV initiation. The UPDI guard time could be reduced if greater margin to meet the deadline is needed.

I also just added a short retry when opening the gpio port, in case the system's udev rules are configured to set permissions on the gpio pin and udev needs a little extra time to do it.

[jhpadjustable]

For information, the quick-and-dirty driver/level-shifter circuit I've been testing with.

[janegilruud]

Not sure if these changes belongs in the master branch. So far pyupdi has been HW agnostic. Do we want to start adding support for specific HW? And in this case, do we want to add support for a "quick-and-dirty driver/level-shifter circuit I've been testing with"?

[xoriath]

Do we want to have some sort of plugin hook infrastructure for this then? It's a valid feature to be able to control this during the entry sequence...

[mraardvark]

I tend to agree with @janegilruud. It maybe better to make a fork of pyupdi as a "board support package" of sorts for your specific hardware... I would like to keep pyupdi as simple and as tested as possible.

[jhpadjustable]

@mraardvark I don't disagree at all. It would be helpful if you or @janegilruud would confirm that my choice of any tinyAVR-1 series chip would satisfy new-UPDI compatibility requirements, or suggest one or two chips that would. As Jan's AVRfreaks post observes, the official public documentation of high voltage UPDI entry is incomplete.

To clarify:

• I am not a Microchip employee. I have only public documentation to inform my work.
• I took care to ensure that the normal, non-HV program flow was undisturbed.
• I have tested my changes using the original, single-resistor interface from the README under the original low-voltage protocol and have successfully connected to, erased, programmed, and read/set fuses on the tiny402 I have to hand.
• Any of the modem control or GPIO outputs available for the HV pulse can be connected to any HV switching circuitry you like, whether true or inverted sense. To me, that open-endedness satisfies any reasonable requirement for HW-agnosticism. I'll build a copy of the STK500 reset driver and test further, with results and any necessary changes to follow.

[metropt]

If we limit the output control to DTR only I think it is a must add to this repo and it is still HW agnostic.