Closed technoblogy closed 1 year ago
That's not a bad idea. I think I often get a warped view of how the GUI looks to people, as the screen on my development computer has a resolution of 3840x2160.... and I see questions about the same things from people,
Would you mind submitting a pull request with these changes (just add some warning/danger/etc word to things that require HV to undo, because otherwise people won't read the docs and will brick their chips and complain to me. (note - boards.txt is still hand-edited. Be sure to use the version in github, not 1.5.2, because there is a single-character typo that is likely the most severe single-character bug that one can conceive of. Burning bootloader on non-optiboot DD to set the "unsafe" fuses put the RESET and UPDI config bits in the wrong place in the byte, resulting in burn bootloader invariably bricking the chip such that HV programming is required to recover.)
*
Per #384, there is a key discrepancy in the datasheet relating to HV UPDI mode such that it is unclear what voltage must be used in order to perform an HV override to reenable UPDI without damaging the target (one chapter says 12V. The electrical characteristics says the pin's absolute max voltage is 9V (implying that following the UPDI chapter could cause physical damage; one of those two numbers is in error, and to even make an HV UPDI programmer or unbricker, one has to deal with the 12v on the controller side.
I am wagering the cost of 40-60 bare boards (by virture of fronting the money for boards assuming that). that it's 12v reset pulse and the abs max is in error
OK, I'll have a go, although I'm not really a GitHub power user.
Are you saying that with 1.5.2, Burn Bootloader on a non-Optiboot AVR64DD14 will brick it?
Does that explain why I'm getting this error?
pymcuprog.pymcuprog_errors.PymcuprogError: UPDI initialisation failed
Yup. Sorry about that.
Completed.
Glad to know it wasn't just me being stupid.
I've just been trying to build a UPDI programmer with HV and couldn't get it to work, so when you make one I'll buy it!
I'll get my boards on Monday, but I unbricked it simpler / stupider: https://github.com/SpenceKonde/DxCore/discussions/378
Although I do like explicit menu options that explain what they do, some of the ones in DxCore are now so long that I can't read them on my Mac laptop; I just get the start and end of the sentence with an ellipsis in the middle. Also, they make the options look pretty daunting.
I'm thinking of this, with AVR-DD-series (Optiboot) and AVR64DD32 selected:
Reset and UPDI pin functions (Bootload burn req'd): "PF6: Reset & PF7: GPIO (DD-compatible HV UPDI required, default boot entry on reset pin & SW)"
I don't think menus should be used for documentation, and I think these should be shortened to a mnemonic, with a full explanation in the README. I suggest:
Reset and UPDI (Bootload burn req'd): "PF6: Reset & PF7: GPIO (see documentation)"
A couple of others are:
Bootloader Serial Port (Bootload burn req'd): "USART0 (default pins): TX PA0, RX PA1 (int. clock only) (on 14-pin: PD6 is led, others PA7)"
The information about which pin the LED is on can be provided on the Pin Mapping/Pinout diagram instead.
Bootloader Entry Condition (Bootload burn req'd): "Default (reset pin and SW reset, 1 sec timeout - unless reset pin disabled, then POR and 8 sec timeout)"
The details in brackets could be in the README.