-
Notifications
You must be signed in to change notification settings - Fork 73
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
HV mode #37
base: master
Are you sure you want to change the base?
HV mode #37
Conversation
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. |
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. |
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"? |
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... |
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. |
@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:
|
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. |
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.