Closed SpenceKonde closed 5 years ago
freemovers
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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.
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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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: spencekonde@gmail.com
On Sat, Sep 21, 2019, 21:15 Bill Westfield notifications@github.com 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 https://github.com/SpenceKonde/megaTinyCore/issues/52?email_source=notifications&email_token=ABTXEW6FVEVKXVYKTFUGU7LQK3BMVA5CNFSM4H3EWPR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7I4NPY#issuecomment-533841599, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTXEW25B6FWE7R37RKIG6DQK3BMVANCNFSM4H3EWPRQ .
SpenceKonde
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago Thanks. I'll be testing these over the next few nights
Some things I am considering:
SpenceKonde
commented
5 years ago 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
commented
5 years ago It detects the clock speed.
SpenceKonde
commented
5 years ago Nice!
SpenceKonde
commented
5 years ago 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
commented
5 years ago WestfW
commented
5 years ago It's in the Optiboot repository; it's just not documented much, yet. :-(
SpenceKonde
commented
5 years ago 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
commented
5 years ago 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 https://github.com/Optiboot/optiboot/issues/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
commented
5 years ago What target do you use? ie, omake drazzy3216 for the txy6 version? and then rename it? Or am I missing something?
SpenceKonde
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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 $< $@
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
commented
5 years ago 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: spencekonde@gmail.com
On Wed, Oct 23, 2019, 23:29 Bill Westfield notifications@github.com 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 https://github.com/SpenceKonde/megaTinyCore/issues/52?email_source=notifications&email_token=ABTXEW7WZW4J2U3FIPBDECTQQEJCHA5CNFSM4H3EWPR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECDSC7A#issuecomment-545726844, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW5TXC3NM4CIO2VQZMLQQEJCHANCNFSM4H3EWPRQ .
This is a long way off, but all these boards have UARTs. We should be able to put a bootloader on them - however considerable work would be required to create a serial bootloader for these, and we have no timeline for this.