Can't burn bootloader

[avandalen]

I have been trying to burn a bootloader into an ATtiny3217 for quite some time now. It does not work. With an unprogrammed, new ATtiny3217, I can burn the bootloader, without an error message, but it does not work, there is no RX communication back from the ATtiny. The UPDI pin was set as reset.

Now I want to burn a bootloader again in the ATtiny3217 with a HV programmer (because the UPDI pin was reset), this doesn't work either.

I use this UPDI HV programmer: https://github.com/wagiminator/AVR-Programmer/tree/master/SerialUPDI_HV_Programmer Uploading sketches works well via the UPDI pin, only without using the 12V HV pulse.

Here are the settings:

This is the error message when burning the bootloader:

SerialUPDI UPDI programming for Arduino using a serial adapter Based on pymcuprog, with significant modifications By Quentin Bolsee and Spence Konde Version 1.2.3 - Jan 2022 Using serial port COM4 at 57600 baud. Target: attiny3217 Set fuses: ['0:0x00', '1:0x00', '2:0x01', '5:0b11000100', '6:0x04', '7:0x00', '8:0x02'] Action: write File: C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10/bootloaders/hex/optiboot_txyz_all8sec.hex Traceback (most recent call last): File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10/tools/prog.py", line 286, in <module> main() File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10/tools/prog.py", line 128, in main return_code = pymcuprog_basic(args, fuses_dict) File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10/tools/prog.py", line 201, in pymcuprog_basic args_start) File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\pymcuprog_main.py", line 545, in _start_session backend.start_session(sessionconfig) File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\backend.py", line 362, in start_session sessionconfig.interface_speed) File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\programmer.py", line 83, in setup_device options=self.options) File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\nvm.py", line 42, in get_nvm_access_provider accessprovider = NvmAccessProviderSerial(transport, device_info, baud=frequency, options=options) File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\nvmserialupdi.py", line 57, in __init__ self.avr.read_device_info() File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\serialupdi\application.py", line 125, in read_device_info self.logger.info("PDI revision = 0x%02X", self.readwrite.read_cs(constants.UPDI_CS_STATUSA) >> 4) File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\serialupdi\readwrite.py", line 25, in read_cs return self.datalink.ldcs(address) File "C:\Users\Albert\AppData\Local\Arduino15\packages\megaTinyCore\hardware\megaavr\2.6.10\tools\libs\pymcuprog\serialupdi\link.py", line 88, in ldcs "{} byte(s) expected {} byte(s)".format(numbytes_received, self.LDCS_RESPONSE_BYTES)) pymcuprog.pymcuprog_errors.PymcuprogError: Unexpected number of bytes in response: 0 byte(s) expected 1 byte(s) Error while burning bootloader.

This is the HV puls and the DTR signal on the scope:

In 2020, burning the bootloader worked fine and I wrote an article about it: https://avdweb.nl/arduino/attiny3217/bootloader-attiny3217

[hmeijdam]

I made the UPDI HV interface (from cannibalized parts) that is part of the schematics of the HV programmer you referenced to. Initially I got the same results as you have. No communication between the serial chip and the tiny. Then I looked at R5 having a value of 1K and thought that to be too high. I lowered it to 500 Ohm, and then the programmer worked. So you may want to try the same.

In the meantime I edited my boards.txt file to enable the expert functions. After disabling the UPDI pin (turn it into reset or GPIO) my normal LV programmer was unable to program, but through my HV plug-on extension it worked even on TURBO speed mode.

[avandalen]

Dear Hans, it doesn't work with 470 Ohm either. Without the HV pulse I can upload as you know, on a new Attiny. I use Windows 10. Is there something wrong with my Arduino IDE? Here are the images etc: 29.txt

[hmeijdam]

Did you try programming through your HV setup, but then with the 12v disconnected on a fresh Attiny and that worked?

I can't see which serial adapter you have from your picture. I am lucky to have one that has NO series resistors. TX and RX go directly to the CH340. If yours has series resistor(s), I think you will have to short that, or you will still have a total resistance of 500 Ohm + the value of the resistor in your serial adapter.

I just finished testing my serial adapters Only the two on the left work through my plug-on HV extension. The common denominator is, that if TX/RX leds, level shifters or TX/RX series resistors are present they fail.

One exception is my UPDI favorite on the far left that has leds on the TX and RX line, but they share one single 1K series resistor to VCC. So besides saving one resistor in production :-) it made UPDI work perfectly.

[avandalen]

Did you try programming through your HV setup, but then with the 12v disconnected on a fresh Attiny and that worked? Yes thats works well. I can upload sketches via UPDI. Also at high speed.

At the FTDI adapter, I removed the series resistor (330Ohm -> 0Ohm on TX) and also any other components that load TX. It seemed illogical to me to remove the 330Ohm resistor on the RX (since this is an input). Can you test this: can a 330 Ohm in series with the RX do any harm?

[avandalen]

Yesterday I bought a very simple adapter on Aliexpres, I don't think it has any resistance: https://nl.aliexpress.com/item/32643085356.html

[hmeijdam]

500 + 330 = 880 ohm. That's close to the 1K that made it fail on my setup.

The UPDI pin of the Attiny needs to pull the RX pin of the CH340 low. Combine this with the UPDI pin having "wet noodle" drive strength, I expect removing the 330 Ohm may lower the resistance to enable the CH340 to detect a low level.

You seem to measure with your scope at the Attiny side of the UPDI. Do a measurement at the RX pin of the CH340 and compare. You may not see a well defined low there.

[avandalen]

No doesn't help. Both are 0 Ohm now on the FTDI adapter. Note that (see above) with an unprogrammed, new ATtiny3217, I can burn the bootloader, without an error message, but it does not work, there is no RX communication back from the ATtiny. Maybe it doesn't work on all computers?

[avandalen]

I had also previously tested whether the HV pulse disrupts things. On a new ATtiny3217 I had lowered the HV to 10V, then I could upload a sketch well. Not with 12V. (must be between 11.5 and 12.5V you know) Have you tested if the bootloader still works on the ATtiny3217?

[hmeijdam]

I have no xxx7 models, only SOP packages, so I tested by disabling the UPDI pin on a 204. I am using a test sketch that blinks a row of leds in a certain pattern, to check if a programming is actually happening or not. I never saw any benefit in using a bootloader on the modern attinies, so have not tested that.

[avandalen]

I can send you some Nano DIPs to test. https://avdweb.nl/arduino/attiny3217/dily3217

What is your address?

[hmeijdam]

mail sent to your al**@.cc address

[SpenceKonde]

There MUST NEVER BE ANY LOAD OF ANY SORT ON THE LINE USED FOR THE RX OF THE UPDI PROGRAMMER in the event that the programmer is made from a modified serial adapter. No RX led AT ALL.

The TX line of the former-serial-adapter may be connected to an activity indicator led and resistor. All such connections required to the TX line must be located between the serial adapter chip, and the first component that is part of the UPDI programmer modifications. There must be no additional connections to anything located between the resistor/diode and the target except the optional 470 ohm or less series resistor

The tinyAVR must be able to drive the pin unambiguously low. Because it's output drivers are about half-way between pullup resistors and pin drivers, on a logarithmic scale (instead of 100 ohm impedance, like an output or 35k like a pullup, driving as hard as it can, PA0 on a tinyAVR has around 2k impedance according to spec).

All of the the components are selected from a narrow strip of terrain between where the target won't register the programmer's lows because there's too much resistance between them, and where the target can hear the programmer but not pull the line low enough for the programmer to see it. If you look at a successful exchange on a scope and take a screen cap, just by looking at how low the lows are, you can visually see which side Somewhere I discuss this (no idea where) and run the numbers and come out to the range of values that would work as the 4.7k resistor in the non-diode scheme has a surprisingly small margin of error - that's why if a diode is used, it MUST be fast signal schottky - a normal schottky won't usually work, and any non schottky will never work. If a resistor is used, other series resistors may need to be removed or the added resistor adjusted, etcetera. The window of parameters that will make this programming method work is tiny. That is why this programming method is so fiddly.

The fiddliness of the hardware is fundamental and unavoidable for all cases where a serial adapter is used as a programmer (and unfortunately the Jtag2UPDI source code might as well be written in greek - I gave up after wasting months trying to make it stop hanging)

[avandalen]

There MUST NEVER BE ANY LOAD OF ANY SORT ON THE LINE USED FOR THE RX OF THE UPDI PROGRAMMER ...................................... All requirements have been met :-) I was able to burn the bootloader without error messages on a new ATtiny3217 but the bootloader does not work, see above.. hmeijdam is trying to find out why the HV programming is not working.

[hmeijdam]

That's done by now. Albert sent me two of his boards to test and first I was as surprised as he was, that my HV programmer did not work on them. I dug up all my Tinies and while testing them I found that a 1626 had the same problem after disabling the UPDI pin. No way back.

I vaguely remembered having red something a few years back about UPDI HV timing requirements on certain parts. Google found me this thread and that's where I decided to rig up this HV programmer. That programmer with included powercycling worked just fine, so I think we can call this matter resolved.

[avandalen]

There is now a conflict with SpenceKonde's description https://github.com/SpenceKonde/jtag2updi "This tool is not recommended anymore"

[hmeijdam]

As a default UPDI programmer I would agree with not using Jtag2UPDI, but use a CH340 serial adapter based solution instead. Works much faster. That's what the recommendation is about. For the small group of users who have disabled their reset pin, want to re-enable it as UPDI again AND are using the Attiny parts that have stricter timing requirements the referenced HV Programmer firmware and hardware, that is based on Jtag2UPDI is required.

[avandalen]

The jtag2updi HV programmer is needed voor the HV programming. I'm going to make a full description on my website on how to provide the ATtiny with a bootloader: https://avdweb.nl/arduino/attiny3217/bootloader-attiny3217.