How to flash using Optiboot/UART on ATtiny1614?

[amadeuspzs]

Apologies for the dumbo question but after scouring the documentation I am none the wiser.

The Optiboot serial bootloader is now supported on these parts, allowing them to be programmed via a serial port.

via which Programmer?

• I have successfully flashed an ATTiny1614 using UPDI and the pyudpi technique; Arduino 1.8.13
• I have successfully burnt the Optiboot bootloader using the alternate UART pins (PA1, PA2), powercycle mode
• When selecting the Board with (optiboot), which Programmer should I use to flash over UART?

None of these options seem to be geared for flashing over UART as per e.g. ArduinoISP?

I am misinterpreting programmed via a serial port to mean programmed over UART as per traditional Arduinos?

[SpenceKonde]

No, you're interpreting it right. The tools -> programmer menu works the same way as it does for official boards: When a board that uses bootloader is selected, and you do "upload" (as opposed to upload using programmer), the tools -> programmer menu option is ignored, and it instead uses the programing parameters specified by the board definition (which for optiboot means serial upload at 115200 baud)

And yeah - it's meant to work the same as serial upload on a normal Arduino. The only problem is that you don't get a hardware reset pin which, ah, kind of sucks., to put it mildly. So you can't use the standard autoreset circuit (0.1uF cap between RST and adapters DTR or RTS, 10k resistor, diode to Vcc) so that opening the serial port with default settings (which drive RTS and DTR low) - unless you disable normal UPDI programming to turn the UPDI pin into a reset pin, which you probably don't want to do..

The two approaches to doing this would be do "ersatz reset" where you put a level interrupt pm a pin and have that call software reset, which would lead to user code bootlooping and execution spending most of it's time in Optiboot - If you had control over the serial console, and could have that not assert DTR/RTS when you were using it to interact with sketch (any good serial console lets you set the state of those pins) when opening the port. But AVRdude still would, and once the bootloader caught wind of the fact that there was an upload starting, it would stop resetting because it would not get to the app, so interrupts would be off.
The other approach is to not have a "Reset" source, but use the 8-second version of the bootloader, which waits 8 seconds for upload after a Power On Reset.

Note that the new 2-series has an alternate reset pin option, which will make optiboot much more pleasant to use on theose parts. But megaTinyCore doesn't support them yet (well, it compiles and uploads, but tons of things are broken.

The protocol used for the upload is same as Uno.

[amadeuspzs]

Thanks so much for the detailed reply @SpenceKonde.

I was indeed trying the 8s approach, but I can't seem to find how to enable this, as all I can see is a 64ms max:

Unless it waits 8s by default, although my blink sketch comes up pretty quickly.

[SpenceKonde]

That... should do it. it's the UPDI/Reset Pin submenu that controls it....

atxy4o.menu.resetpinopti.UPDI=UPDI (powercycle to enter bootloader)
atxy4o.menu.resetpinopti.UPDI.bootloader.file=optiboot_x/optiboot_txyz{bootloader.uartswap}.hex
atxy4o.menu.resetpinopti.UPDI.bootloader.resetpinbits=01
atxy4o.menu.resetpinopti.UPDIErsatzReset=UPDI, bootloader uses ersatz reset pin
atxy4o.menu.resetpinopti.UPDIErsatzReset.bootloader.file=optiboot_x/optiboot_txyz{bootloader.uartswap}_1sec.hex
atxy4o.menu.resetpinopti.UPDIErsatzReset.bootloader.resetpinbits=01
atxy4o.menu.resetpinopti.UPDIaltrst=UPDI w/alternate reset (2-series only)
atxy4o.menu.resetpinopti.UPDIaltrst.bootloader.file=optiboot_x/optiboot_txyz{bootloader.uartswap}_rst.hex
atxy4o.menu.resetpinopti.UPDIaltrst.bootloader.resetpinbits=11
atxy4o.menu.resetpinopti.reset=Reset (DANGER - Read docs first!)
atxy4o.menu.resetpinopti.reset.bootloader.file=optiboot_x/optiboot_txyz{bootloader.uartswap}_rst.hex
atxy4o.menu.resetpinopti.reset.bootloader.resetpinbits=10
atxy4o.menu.resetpinopti.gpio=IO (DANGER - Read docs first! powercycle to enter bootloader)
atxy4o.menu.resetpinopti.gpio.bootloader.file=optiboot_x/optiboot_txyz{bootloader.uartswap}.hex
atxy4o.menu.resetpinopti.gpio.bootloader.resetpinbits=00

See! Clear as crystal right?
...
...

One thing I didn't do a good job on was the naming of the optiboot binaries...

with no postfix, it will wait 8 seconds after a POR, hardware reset or software reset (WDT resets will go straight to app, since that's how the bootloader exits while ensuring the app gets a clean slate.

With _1sec, it will only wait 1 second, but have same set of things that can trigger it (intended for ersatz reset, where you still need to be able to recover it you upload a bad sketch.so it still runs after POR.

With _rst, it's 1 second, but it only runs after software reset or hardware (reset pin ) reset.

[amadeuspzs]

Thanks. I'm not having much luck on either UART port for programming.

My flow is:

1. Burn bootloader via UPDI
2. Switch serial controller to the UART pins selected
3. Unplug/replug the serial controller which is also providing my power - this should give me 8 seconds
4. Upload via Arduino and the (optiboot) board selected within 8 seconds
5. No dice: stk500_recv(): programmer is not responding

I'd like to use the bootloader LED to check it's working.

I am correct in understanding:

1. Bootloader LED is A7 = PIN_PA7
2. Bootloader LED is set to flash 3 times on startup, on external reset (does power cycle count?)
3. What is the polarity of the LED? Ie. is it a source or sink? I've tried both and no luck

[SpenceKonde]

It is expecting that the LED will be connected such that a high on PA7 would turn on the LED. The triple-blink should be observed any time the entry conditions are met: after power-on reset, software reset, or reset-pin reset (though the latter can't happen, since we dont have a reset pin. I would certainly expect to see the triple blink immediately after uploading the bootloader if the LED was in place at that time (I'd also recommend a sanity check: uploading blink via UPDI to make sure the LED is connected correctly , to the correct pin and that there isn't some other problem)

[amadeuspzs]

Very strange. I have:

1. Verified PA7 blinks correctly
2. If I burn the bootloader with blink code, PA7 stays on indefinitely (no blink)
3. If I burn the bootloader without blink code, PA7 stays off (no blink)
4. I tried another chip

FWIW I'm using an ATTiny1614

I'm stumped. I'm happy to flash over UPDI and debug over UART, once my second USB serial adapter arrives!

[SpenceKonde]

what do you mean with blink code, or without blink code?

[amadeuspzs]

It appears that the bootloader behaves differently depending on what application code was flashed on the chip before burning the bootloader, specifically application code writing to PA5 or PA7 (I haven't tried other ports) "freezes" once burning the bootloader:

1. Blank sketch via UPDI + bootloader = no activity on PA7 on power-on reset (not even three flashes)
2. Blink sketch on PA pin (I've tried PA5 and PA7) via UPDI + bootloader = whatever PA pin was blinking now permanently on (e.g. PA5 or PA7, or both if both were blinking before). Note that the sketch is frozen aka doesn't run at all.
3. Non-blink sketch via UPDI (e.g. Serial blink) + bootloader = no activity on PA7 but application runs correctly.

So it looks like there is some persistence/crossover between application code that writes to PA5/7 and the bootloader which makes absolutely no sense at all?

Sorry for the continued issue - if someone can confirm they have got this working on ATTiny1614 I would be happy to admit defeat and close the issue.

[SpenceKonde]

What are you using to flash it? When you disconnect power and then reconnect it it should be the same either way, right?. I think that's just the exit from UPDI being done uncleanly...

…

On Sun, Feb 14, 2021 at 5:24 AM Amadeus ***@***.***> wrote: It appears that the bootloader behaves differently depending on what application code was flashed on the chip before burning the bootloader: 1. Blank sketch via UPDI + bootloader = no activity on PA7 on power-on reset (not even three flashes) 2. Blink sketch on PA pin (I've tried PA5 and PA7) via UPDI + bootloader = whatever PA pin was blinking now permanently on (e.g. PA5 or PA7, or both if both were blinking before). Note that the sketch is frozen aka doesn't run at all. So it looks like there is some persistence/crossover between application code and bootloader which makes absolutely no sense at all? Does burning the bootloader preserve the application code? Sorry for the continued issue - if someone can confirm they have got this working on ATTiny1614 I would be happy to admit defeat and close the issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#320 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW3BLZOPEPR3JZ2ZEMLS66QG7ANCNFSM4XRMMZMA> .

--

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for all pre-2016 tinyAVR with >2k flash! megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support for all post-2016 tinyAVR parts! DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR Dx-series parts, the latest and greatest from Microchip! Contact: spencekonde@gmail.com

[amadeuspzs]

Here is the flashing circuit, using a FT232RL USB adapter:

Here is the burn bootloader command:

/Users/xxx/Library/Arduino15/packages/megaTinyCore/tools/python3/3.7.2-post1/python3 -u /Users/xxx/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.2.7/tools/prog.py -t uart -u /dev/cu.usbserial-AQ00K54V -d attiny1614 -v --fuses 0:0x00 1:0x00 2:0x02 4:0x00 5:0b11000100 6:0x04 7:0x00 8:0x02 -d attiny1614 -f/Users/xxx/Library/Arduino15/packages/megaTinyCore/hardware/megaavr/2.2.7/bootloaders/optiboot_x/optiboot_txyz_alt.hex -a write

and verbose output edit - moved to a gist as lengthy

[ArnieO]

@amadeuspzs
Sorry, but your UART schematic does not make much sense to me.
You need to connect to the designated Rx/Tx pins on the ATtiny, which are PB2 and PB3:

FTDI Rx -> ATtiny Tx
FTDI Tx -> ATtiny Rx
FTDI GND -> ATtiny GND
You may also connect FTDI Vcc -> ATtiny Vcc , but you need to power cycle the ATtiny at most 8 seconds before the upload starts, so you might want to consider an other power source to simplify that.

[SpenceKonde]

His schematic depicts the pyupdi programming method, where you have a serial adapter, it's TX connected to RX through a 4.7k resistor and and RX connected straight to the UPDI line. and directly program a UPDI chip.. megaTinyCore and DxCore include a tool for uploading in this way (a wrapper around a version of pymcuprog from Microchip)

[amadeuspzs]

Hi @SpenceKonde I've just tried again with a CH340G USB serial adapter, and again, I don't get any flashes on PA7, although this time the LEDs aren't permanently on (they are not running the application code either, and I am not able to flash over UART).

So this issue remains I'm afraid.

Does anyone out there have an ATtiny1614 they can try?

[pfoun]

@amadeuspzs Optiboot upload with UART works for me on the ATtiny1614. Here is what I did:

1. Chose Optiboot version of ATtiny1614 from the menu and burned bootloader with jtag2updi programmer.
2. The serial adapter I have is CP2102. Connect serial adapter tx to physical pin 6 and rx to physical pin 7
3. 5V to pin 1 and GND to pin 14
4. LED anode attached to physical pin 5 and cathode to GND
5. On power up LED flashes 3 times and after 8 seconds, aplication starts.
6. I uploaded the blink sketch and it works as expected on PA7, physical pin 5

[Dlloydev]

@amadeuspzs: Is the target at 3.3V or 5V? (the FT232RL USB adapter might have a 3.3V-5V jumper)
If the ATtiny1614 is on an SOIC adapter, does it have a ceramic 0.1µF decoupling/bypass capacitor across VCC and GND?

[amadeuspzs]

Thanks @pfoun and @Dlloydev for the followup:

1. I've tried both 3.3V and 5V, and with/without decoupling cap
2. I've only been able to try the "Serial port and 4.7k (pyupdi style)" method, but once I get my hands on a spare arduino I will try the jtag2updi method

Perhaps burning the bootloader pyupdi style is not as viable?

[ArnieO]

once I get my hands on a spare arduino I will try the jtag2updi method

I use an Arduino Nano / jtag2updi method on an ATtiny1616. It works really well, and also lets me switch to serial pin programming. (Sorry, I don't have a 1614 to test on.)
Word of caution: I bricked one ATtiny trying to switch from serial programming back to UPDI programming, but I suspect "user error" to be the cause of that. 😬

[SpenceKonde]

@ArnieO - there should be only one way to brick a tiny with megaTinyCore, and that is setting updi pin to be used as reset or gpio which require an HV programmer to program further - when you don't have one of those.

[SpenceKonde]

you want 5v, with decoupling cap.

have you verified that there is no resistor in series with the TX line already? many serial adapters have one on-board to protect against a short on the target damaging adapter or 5v adapter damaging lower voltage target. if one is present you will need a correspondingly smaller resistor between Tx and Rx

[amadeuspzs]

Ok, after bootloading an ATMega328P and loading up jtag2updi, I can confirm that jtag2updi is working - bootloader loads correctly, and I can flash over UART.

My only conclusion is that burning the bootloader is not viable using the "Serial port and 4.7k (pyupdi style)" method.

I'll add a PR to mention this in the documentation.

[SpenceKonde]

Okay, we need to figure out what is actually happening here. If there is a defect in the core, we need to figure that out ASAP, and get word to he who wrote the prog.py shim that goes between pymcuprog and the IDE that we have a problem.

Here is the thing that I find very strange. You report it not working,... BUT YOU ALSO DO NOT REPORT ANY ERRORS. It sounds to me like the process is completing without throwing errors, yet resulting in a non-working device? Is that an accurate statement?

[SpenceKonde]

I have reproduced the problem.

[amadeuspzs]

😅 I was really dreading user error here... Happy to test any patches etc. Is it worth keeping/merging the PR until this issue is fixed?

[SpenceKonde]

It is fixed in 2.2.8 megaTinyCore and 1.3.2 DxCore. These are available for manual download from the releases section as well as board manager installation.