Bootloader support #52
Comments
|
There is an appnote for a basic bootloader using UART or TWI: |
|
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. |
|
So... This has been happening, over in https://github.com/Optiboot/optiboot land... 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...) |
|
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? |
|
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) |
|
Sure, that works for you and me and Hans... |
|
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 ***@***.***> 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>
.
|
|
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? |
|
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) |
|
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. |
|
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. |
|
Thanks. I'll be testing these over the next few nights Some things I am considering:
|
|
Does the bootloader detect the internal oscillator clock speed and adjust it's baud rate accordingly, or does it assume one or the other? |
|
It detects the clock speed. |
|
Nice! |
|
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 |
|
It's in the Optiboot repository; it's just not documented much, yet. :-( |
|
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. |
|
Hmm. I haven't looked at omake in a long time; your strategy is ... uncommon. |
|
What target do you use? ie, omake drazzy3216 for the txy6 version? and then rename it? Or am I missing something? |
|
Okay, I have gotten the bootloaders to build with my hacked up build environment with a modified makefile. One thing I noticed that I don't understand in both your hex files and the ones I build.... The bootloader section is 512b. With yours:
Mine
This must be erased when the sketch is uploaded. Do you understand what this is for, or why it's there? |
|
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. |
|
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... |
|
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. |
|
That would be easy enough to do in the "avr-objcopy" stage In the makefile, I think. $(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... |
|
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 ***@***.***> 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>
.
|
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.
The text was updated successfully, but these errors were encountered: