Bootloader support about megatinycore

[freemovers]

There is an appnote for a basic bootloader using UART or TWI:
https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en604508
Looks like WestfW is working on getting optiboot to work on the ATmega4809 as well, and that should be pretty easy to use on the 0- and 1- series.

[SpenceKonde]

Yeah, I heard he was working on that. Once he gets optiboot working on the megaAVR boards, I think we'll be able to bring it to the Tiny's without much difficulty.

[WestfW]

So... This has been happening, over in https://github.com/Optiboot/optiboot land...
Bootloaders on the new chips are easier than on the old chips, and much more consistent from chip to chip. (in fact, it looks like the same bootloader binary should run on all of the 14, 20, and 24 pin DrAzzy xTiny boards, since they all have the LED on A7 and the UART on B2/B3...)

The big problem is that the RESET and UPDI share a pin. To get the desirable Arduino auto-reset, you have to disable future UPDI programming/debugging (unless you have a programmer with High Voltage UPDI available. And those seem quite rare.)

See also: https://github.com/WestfW/megaTinyCore/commits/master

(the exciting part is at the end...)

  : Blah blah blah...
Build options changed, rebuilding all
Detecting libraries used...
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-g++ -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=attiny412 -DF_CPU=20000000L -DARDUINO=10809 -DARDUINO_attinyxy2 -DARDUINO_ARCH_MEGAAVR -DMILLIS_USE_TIMERA0 -DNO_EXTERNAL_I2C_PULLUP -DDACVREF=0 -DNEOPIXELPORT=VPORTA.OUT -DUARTREMAP -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/cores/arduino/api/deprecated -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/cores/arduino -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/variants/txy2 /tmp/OldArduBuild/sketch/Blink.ino.cpp -o /dev/null
Generating function prototypes...
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-g++ -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=attiny412 -DF_CPU=20000000L -DARDUINO=10809 -DARDUINO_attinyxy2 -DARDUINO_ARCH_MEGAAVR -DMILLIS_USE_TIMERA0 -DNO_EXTERNAL_I2C_PULLUP -DDACVREF=0 -DNEOPIXELPORT=VPORTA.OUT -DUARTREMAP -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/cores/arduino/api/deprecated -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/cores/arduino -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/variants/txy2 /tmp/OldArduBuild/sketch/Blink.ino.cpp -o /tmp/OldArduBuild/preproc/ctags_target_for_gcc_minus_e.cpp
/Applications/Arduino-1.8.9.app/Contents/Java/tools-builder/ctags/5.8-arduino11/ctags -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives /tmp/OldArduBuild/preproc/ctags_target_for_gcc_minus_e.cpp
Compiling sketch...
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-g++ -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -mmcu=attiny412 -DF_CPU=20000000L -DARDUINO=10809 -DARDUINO_attinyxy2 -DARDUINO_ARCH_MEGAAVR -DMILLIS_USE_TIMERA0 -DNO_EXTERNAL_I2C_PULLUP -DDACVREF=0 -DNEOPIXELPORT=VPORTA.OUT -DUARTREMAP -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/cores/arduino/api/deprecated -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/cores/arduino -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/variants/txy2 /tmp/OldArduBuild/sketch/Blink.ino.cpp -o /tmp/OldArduBuild/sketch/Blink.ino.cpp.o
Compiling libraries...
Compiling core...
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-gcc -c -g -Os -w -std=gnu11 -ffunction-sections -fdata-sections -MMD -flto -fno-fat-lto-objects -mmcu=attiny412 -DF_CPU=20000000L -DARDUINO=10809 -DARDUINO_attinyxy2 -DARDUINO_ARCH_MEGAAVR -DMILLIS_USE_TIMERA0 -DNO_EXTERNAL_I2C_PULLUP -DDACVREF=0 -DNEOPIXELPORT=VPORTA.OUT -DUARTREMAP -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/cores/arduino/api/deprecated -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/cores/arduino -I/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/variants/txy2 /Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/variants/txy2/variant.c -o /tmp/OldArduBuild/core/variant.c.o
Using precompiled core: /var/folders/gv/zn3wcml52jq0vvjnd95j8g6h0000gp/T/arduino_cache_347500/core/core_7de764dba9ce39d0e69d64e6f8a34b87.a
Linking everything together...
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-gcc -w -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections -Wl,--section-start=.text=0x200 -mmcu=attiny412 -o /tmp/OldArduBuild/Blink.ino.elf /tmp/OldArduBuild/sketch/Blink.ino.cpp.o /tmp/OldArduBuild/core/variant.c.o /tmp/OldArduBuild/../../var/folders/gv/zn3wcml52jq0vvjnd95j8g6h0000gp/T/arduino_cache_347500/core/core_7de764dba9ce39d0e69d64e6f8a34b87.a -L/tmp/OldArduBuild -lm
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-objcopy -O binary -R .eeprom /tmp/OldArduBuild/Blink.ino.elf /tmp/OldArduBuild/Blink.ino.bin
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/OldArduBuild/Blink.ino.elf /tmp/OldArduBuild/Blink.ino.eep
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-objcopy -O ihex -R .eeprom /tmp/OldArduBuild/Blink.ino.elf /tmp/OldArduBuild/Blink.ino.hex
chmod +x /Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/create_disassembler_listing.sh
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/create_disassembler_listing.sh /Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-objdump "--disassemble --source --line-numbers --demangle --section=.text" /tmp/OldArduBuild/Blink.ino.elf /tmp/OldArduBuild/Blink.ino.lst
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avr-gcc/7.3.0-atmel3.6.1-arduino5/bin/avr-size -A /tmp/OldArduBuild/Blink.ino.elf
Sketch uses 1070 bytes (26%) of program storage space. Maximum is 4096 bytes.
Global variables use 22 bytes (8%) of dynamic memory, leaving 234 bytes for local variables. Maximum is 256 bytes.
/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/avrdude -C/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/avrdude.conf -v -pattiny412 -carduino -P/dev/cu.usbserial-FTD61T6Q -D -Uflash:w:/tmp/OldArduBuild/Blink.ino.hex:i 

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/Applications/Arduino-1.8.9.app/Contents/Java/portable/packages/megaTinyCore/hardware/megaavr/1.0.5/avrdude.conf"
         User configuration file is "/Volumes/MacOS/HD-Users/BillW/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbserial-FTD61T6Q
         Using Programmer              : arduino
         AVR Part                      : ATtiny412
         Chip Erase delay              : 0 us
         PAGEL                         : P00
         BS2                           : P00
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 0
         StabDelay                     : 0
         CmdexeDelay                   : 0
         SyncLoops                     : 0
         ByteDelay                     : 0
         PollIndex                     : 0
         PollValue                     : 0x00
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           prodsig        0     0     0    0 no         61   61      0     0     0 0x00 0x00
           fuses          0     0     0    0 no          9    0      0     0     0 0x00 0x00
           fuse0          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse1          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse2          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse4          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse5          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse6          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse7          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           fuse8          0     0     0    0 no          1    0      0     0     0 0x00 0x00
           lock           0     0     0    0 no          1    0      0     0     0 0x00 0x00
           data           0     0     0    0 no          0    0      0     0     0 0x00 0x00
           usersig        0     0     0    0 no         32   32      0     0     0 0x00 0x00
           flash          0     0     0    0 no       4096   64      0     0     0 0x00 0x00
           eeprom         0     0     0    0 no        128   32      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 3
         Firmware Version: 9.0
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9223 (probably t412)
avrdude: reading input file "/tmp/OldArduBuild/Blink.ino.hex"
avrdude: writing flash (1582 bytes):

Writing | ################################################## | 100% 0.29s

avrdude: 1582 bytes of flash written
avrdude: verifying flash memory against /tmp/OldArduBuild/Blink.ino.hex:
avrdude: load data flash data from input file /tmp/OldArduBuild/Blink.ino.hex:
avrdude: input file /tmp/OldArduBuild/Blink.ino.hex contains 1582 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.34s

avrdude: verifying ...
avrdude: 1582 bytes of flash verified

avrdude done.  Thank you.

[SpenceKonde]

THANK YOU! This is amazing news!! Is it ready for me to start banging on now?

Don't the sketch binaries have to be generated with a different start address?

Do we also have to set the fuses that define the app and boot areas? I imagine we'd have to?

[SpenceKonde]

Look more closely at the HVSP process - it's not like on the other parts.

What you do is apply a brief (500us worked, but people had problems doing it by manually touching wires) pulse to the RESET/UPDI pin, and then pull it to ground. Have your UPDI programmer connected (the 4.7k resistor keeps it safe) while you apply this pulse. Then program the chip normally - the pulse makes the pin act like a UPDI pin again.

I have been able to recover chips with this method (using a super simple sketch to apply a 500us pulse when a button was pressed, through an NPN and PNP, and a few resistors), while the UPDI programmer (it's UPDI pin protected by the 4.7k resistor) is connected, then program normally. Easy-peasy. Though it's still of course incompatible with the autoreset circuit being connected (and that diode in said circuit is more necessary than ever, because that pulse when DTR was released would be much more likely to put the part into a bad state vs a classic AVR)

[WestfW]

Sure, that works for you and me and Hans...
Have you noticed whether the autoreset cap interferes with UPDI (if the pin is in UPDI mode)?

[SpenceKonde]

Have not investigated. My boards have a spot on the bottom where you can cut a trace to disconnect all the autoreset then rejoin with a blob of solder (second rev of boards will not have this connected by default, so I can load all parts, bootload and then connect that jumper to enable the autoreset - and it would only need to be disconnected if it had to be re-bootloaded, after which it could be reconnected. Hopefully, people wont have to be updi programming a device after its bootloaded. I cant imagine how the cap would not be a problem if something was connected to it (ie, the dtr line of a serial adapter), nor how it would be if not. The 4.7k in series with programmer and 10k pull up would also act as a voltage divider, which I'm more worried about.

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: [email protected]

On Sat, Sep 21, 2019, 21:15 Bill Westfield ***@***.***> wrote: Sure, that works for you and me and Hans... Have you noticed whether the autoreset cap interferes with UPDI (if the pin is in UPDI mode)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#52?email_source=notifications&email_token=ABTXEW6FVEVKXVYKTFUGU7LQK3BMVA5CNFSM4H3EWPR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7I4NPY#issuecomment-533841599>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABTXEW25B6FWE7R37RKIG6DQK3BMVANCNFSM4H3EWPRQ> .

[SpenceKonde]

So- Is it time for me to start trying these out and integrating them with the core?

If so, what do I need to know about making use of them, if anything?

[WestfW]

Give me a couple days, and I'll submit a pull request that covers at least some of the basics.

Are you specifically avoiding board types for the XPplained (attiny817) and Xplained Nano boards? (attiny416)

[SpenceKonde]

That would be amazing!

I am not specifically avoiding it. I have yet to be asked about it though. I have an XPlained mini (I think) sitting in a bin somewhere, but I haven't taken it out of the bag. So what I'm saying I guess is I haven't thought about it, and assumed nothing special was required for them. If they require a separate board type, then I should definitely add them.

[SpenceKonde]

Context/planning note: 1.0.6 will be released before these changes are merged; first release with the bootloader will be released as 1.1.0.

[SpenceKonde]

Thanks. I'll be testing these over the next few nights

Some things I am considering:

• Burn botloader should probably set all the fuses
• May add a submenu for Optiboot boards with option for UPDI or Reset pin function - in the latter case, I'd build a second set of binaries with the short startup delay. In the boards I sell with optiboot, I plan to have the bootloader burned and the pin set as reset with autoreset.
• May add build for the other UART pins on xy2

[SpenceKonde]

Does the bootloader detect the internal oscillator clock speed and adjust it's baud rate accordingly, or does it assume one or the other?

[WestfW]

It detects the clock speed.

[SpenceKonde]

Nice!

[SpenceKonde]

Where can I find the source code for optiboot_x? I don't see a repo for that in either your repositories or the github.com/Optiboot

[MCUdude]

https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/optiboot_x.c

[WestfW]

It's in the Optiboot repository; it's just not documented much, yet. :-(

[SpenceKonde]

Hi

I finally had a chance to come back to this. How do I invoke omake to build the bootloader? I'm ripping out my hair here, none of the ways I used to build optiboot work anymore.

How do I get it to find my avrgcc installation?

What I have always done is start with the an installation of 1.0.6 from .zip, so it got all the tools, and then copy the newer version of the compiler in place of the old one. This used to work on old versions of optiboot, including the one that ATTinyCore uses; worked flawlessly, never had any problems. But now everything has been changed in the makefile, and I have had a hell of a time trying to tell it that the bloody compiler toolchain is in ../../../tools/avr/bin

Through lots of cut and paste from the makefile I use with the attinycore builds, I've gotten it to generate a .hex file by replacing omake.bat with the version pointing to where make actually is, and by specifying omake drazzy3216; but the .hex file generated in this way (using the 7.3.0 compiler toolchain) does not match the one you supplied (it is similar in length, but lots of differences in the data). And your files are named optiboot_txy6.hex (for example). Were these manually renamed, or am I doing yet another thing wrong?

What am I doing wrong here? How can I tell your make scripts where to find my copy of avrgcc without having to hack up the makefiles and modify omake.bat?

Am building on windows.

[WestfW]

Hmm. I haven't looked at omake in a long time; your strategy is ... uncommon.
I've been using the avr8-atmel-3.6.1.495 CLI toolchain install (but I'm on a Mac, so I already have "make" installed.) Which has avr-gcc 5.4 (https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers )
Since the Arduino install stopped including Make, as well as moving everything around, I've been lax on supporting "easier" methods of installing a toolchain. (See Optiboot/optiboot#118 - only 4.5y old.)
Now, for the new chips, you need the Atmel "packs" as well (although the Arduino build of the compiler doesn't seem to use them. :-(

[SpenceKonde]

What target do you use? ie, omake drazzy3216 for the txy6 version? and then rename it? Or am I missing something?

[SpenceKonde]

Okay, I have gotten the bootloaders to build with my hacked up build environment with a modified makefile.
The 7.3.0 compiler generates different hex files, but they still work.

One thing I noticed that I don't understand in both your hex files and the ones I build....

The bootloader section is 512b.
The compiled bootloader is 477b.
The hex file contains 32b of data after 512b (after a gap between the end of the compiled binary, then there's the bootloader version at the end of the 512b section... then there are these 32 bytes in the beginning of the app section!

With yours:

:10020000E0E4F0E0808180838091FE019091FF0125
:1002100040E050E064E080E090E0C2DF0C94000039

Mine

:10020000E0E4F0E0808180838091FE019091FF0125
:1002100050E040E064E090E080E0C5DF0C94000036

This must be erased when the sketch is uploaded. Do you understand what this is for, or why it's there?
I can delete it, and the bootloader still works.

[SpenceKonde]

Got them building. I think it's all in.

Thanks for making this possible!

Still interested to hear any thoughts on those mysterious 32-bytes.

[WestfW]

I load up a "dummy" application, which does pretty much nothing but jump back to the bootloader (the same as executing no-ops till the address wraps around.) Originally, I was using this to adjust the reset causes (before I gave up), as an aid in debugging, and to try out the "software reset" function. But recently I realized that this will also serve as a size-check of the bootloader - without it, the bootloader could grow bigger than 512 bytes and just keep going in memory. With the application there, I should get linker errors about the boot and application sections colliding...
https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/optiboot_x.c#L713

[SpenceKonde]

I think I may remove this dummy program from the .hex files; I am concerned that the dummy program will cause problems with the product of "export compiled binaries" for the merged bootloader + sketch option, and it would be cool to be able to enable that here.

[WestfW]

That would be easy enough to do in the "avr-objcopy" stage In the makefile, I think.
Just omit the -j for the .application section:

$(OBJCOPY) -j .text -j .data -j .version --set-section-flags .version=alloc,load -j .application -O ihex $&lt; $@

Huh. Note that most of the features of the .application that I mentioned "work" even if the code isn't actually there. That probably means that I shouldn't bother copying it into the .hex file at all...

[SpenceKonde]

Oh sweet. Thanks. The hex files in the core right now... were done by hand.

…

____________ Spence Konde Azzy’S Electronics New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: [email protected]

On Wed, Oct 23, 2019, 23:29 Bill Westfield ***@***.***> wrote: That would be easy enough to do in the "avr-objcopy" stage In the makefile, I think. Just omit the -j for the .application section: $(OBJCOPY) -j .text -j .data -j .version --set-section-flags .version=alloc,load *-j .application* -O ihex $< $@ — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#52?email_source=notifications&email_token=ABTXEW7WZW4J2U3FIPBDECTQQEJCHA5CNFSM4H3EWPR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECDSC7A#issuecomment-545726844>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTXEW5TXC3NM4CIO2VQZMLQQEJCHANCNFSM4H3EWPRQ> .