Replies: 3 comments
-
We prebuild two versions ofeach configuration:
You want "Only run bootloader on software reset". The file is optiboot_x.c included with this core. I build on Windows: I take a 1.0.6 arduino zip package, overwrite the toolchain with the latest version (azd6, see the boardmanager json for the URL to download from), and delete everything from the directory except hardware and tools. I've got 2 installs like that, one with 5.4 for ATTinyCore and one with 7.3 azd6 for megaTinyCore and DxCore. I keep a zipped copy of arduino 1.0.6 with just the build tools handy. It gets run from the makeall batch file generally. I just checked in (untested) an entry condition to handle this, build with START_APP_UNLESS_SWR defined and it should immediately run the app. Be careful with that option, as it leaves no way to recover if the application code never fires a software reset - ie, don't do that unless you leave PA0 as UPDI or have an HV programmer, unless you want to end up with a bin of bricked boards gathering dust, marked "Needs HV reprogramming to use" (like I have). I have definitely removed the chip from boards and replaced it with a new one in preference to sorting out HV reprogramming, even though I have a couple of programmers, somewhere, because there's no mystery to that: Pop it onto a hotplate at around 210 C, watch it heat up, and as soon as the solder joints melt, pluck the chip off, and put a new one in it's place, couple minutes of work once the hotplat is at temperature. (210C is assuming tin/lead solder. You want something like 25C, minimum, above liquidus for whatever solder you're using, so more like 250 for classic lead free, while bismuth-bearing solders can be done with lower temperatures). Much less work than learning how to use an hv updi programmer) |
Beta Was this translation helpful? Give feedback.
-
Dear Mr. Konde,
I am aware of most of what you wrote. But as a hardware engineer, I just was not sure about where in optiboot_x.c I need to change what to modify the start behavior.
And I was not totally clear about the available configurations. You now wrote it is “Only run bootloader on software reset or external reset”.
To my understanding, “external reset” is a reset triggered by a physical (reset)pin on the device, which does not exist on ATTINY1616 by default. So , this option would have suited my needs. BUT in contrast, other documentation says it is “run bootloader on software reset an power up reset” which is what I cannot use.
Anyhow, thank you very much for creating the new version. I’ll give it a try. What do you recommend to trigger a SW reset ? Simply jump to address 0?
Oh, and as I mess with uCs every day, I am very aware of the bricking danger. Albeit I only managed to brick 2 or 3 devices in over 20 years 😊
I will not disable UPDI 😊 And even if: I have a selection of hot plates and hot air guns and a small reflow oven ….
Von: Spence Konde (aka Dr. Azzy) ***@***.***>
Gesendet: Mittwoch, 26. Oktober 2022 19:21
An: SpenceKonde/megaTinyCore ***@***.***>
Cc: Wolfgang Ebersbach ***@***.***>; Author ***@***.***>
Betreff: Re: [SpenceKonde/megaTinyCore] Customized Optiboot HowTo ? (Discussion #851)
We prebuild two versions ofeach configuration:
* Only run bootloader on software reset or external reset
* Run bootloader unless last reset was from WDT.
You want "Only run bootloader on software reset".
The file is optiboot_x.c included with this core.
I build on Windows: I take a 1.0.6 arduino zip package, overwrite the toolchain with the latest version (azd6, see the boardmanager json for the URL to download from), and delete everything from the directory except hardware and tools. I've got 2 installs like that, one with 5.4 for ATTinyCore and one with 7.3 azd6 for megaTinyCore and DxCore. I keep a zipped copy of arduino 1.0.6 with just the build tools handy. It gets run from the makeall batch file generally.
I just checked in (untested) an entry condition to handle this, build with START_APP_UNLESS_SWR defined and it should immediately run the app.
Be careful with that option, as it leaves no way to recover if the application code never fires a software reset - ie, don't do that unless you leave PA0 as UPDI or have an HV programmer, unless you want to end up with a bin of bricked boards gathering dust, marked "Needs HV reprogramming to use" (like I have).
I have definitely removed the chip from boards and replaced it with a new one in preference to sorting out HV reprogramming, even though I have a couple of programmers, somewhere, because there's no mystery to that: Pop it onto a hotplate at around 210 C, watch it heat up, and as soon as the solder joints melt, pluck the chip off, and put a new one in it's place, couple minutes of work once the hotplat is at temperature. (210C is assuming tin/lead solder. You want something like 25C, minimum, above liquidus for whatever solder you're using, so more like 250 for classic lead free, while bismuth-bearing solders can be done with lower temperatures). Much less work than learning how to use an hv updi programmer)
—
Reply to this email directly, view it on GitHub<#851 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A32S4Q7P65Z6JZ3XFFFI2ZLWFFR7RANCNFSM6AAAAAARO75XPE>.
You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>
|
Beta Was this translation helpful? Give feedback.
-
Jump to zero is something you should never ever do. Not on a classic avr,
and definitely not a modern one. It is a "dirty reset" and produces
undefined behavior because all the initialization code assumes peripheral
registers are in reset state. The proper way to issue a software reset is
by doing _PROTECTED_WRITE(SWRR,1) (phone sent, not sure if it's one or two
underscores at the start). Since the 2016 revoluyion weve had a proper sw
reset See Ref_Reset.md in megaavr/extras for the whole explanation of how
improper handling of accidentally dirty resets likely caused the majority
of hangs on avrs that require external reset or power cycle to revive. They
were bad news on classic avrs but much worse now because the chance if
coming back in a working state is lower
…____________
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: ***@***.***
On Thu, Oct 27, 2022, 02:18 WebGH ***@***.***> wrote:
Dear Mr. Konde,
I am aware of most of what you wrote. But as a hardware engineer, I just
was not sure about where in optiboot_x.c I need to change what to modify
the start behavior.
And I was not totally clear about the available configurations. You now
wrote it is “Only run bootloader on software reset or external reset”.
To my understanding, “external reset” is a reset triggered by a physical
(reset)pin on the device, which does not exist on ATTINY1616 by default. So
, this option would have suited my needs. BUT in contrast, other
documentation says it is “run bootloader on software reset an power up
reset” which is what I cannot use.
Anyhow, thank you very much for creating the new version. I’ll give it a
try. What do you recommend to trigger a SW reset ? Simply jump to address
0?
Oh, and as I mess with uCs every day, I am very aware of the bricking
danger. Albeit I only managed to brick 2 or 3 devices in over 20 years 😊
I will not disable UPDI 😊 And even if: I have a selection of hot plates
and hot air guns and a small reflow oven ….
Von: Spence Konde (aka Dr. Azzy) ***@***.***>
Gesendet: Mittwoch, 26. Oktober 2022 19:21
An: SpenceKonde/megaTinyCore ***@***.***>
Cc: Wolfgang Ebersbach ***@***.***>; Author ***@***.***>
Betreff: Re: [SpenceKonde/megaTinyCore] Customized Optiboot HowTo ?
(Discussion #851)
We prebuild two versions ofeach configuration:
* Only run bootloader on software reset or external reset
* Run bootloader unless last reset was from WDT.
You want "Only run bootloader on software reset".
The file is optiboot_x.c included with this core.
I build on Windows: I take a 1.0.6 arduino zip package, overwrite the
toolchain with the latest version (azd6, see the boardmanager json for the
URL to download from), and delete everything from the directory except
hardware and tools. I've got 2 installs like that, one with 5.4 for
ATTinyCore and one with 7.3 azd6 for megaTinyCore and DxCore. I keep a
zipped copy of arduino 1.0.6 with just the build tools handy. It gets run
from the makeall batch file generally.
I just checked in (untested) an entry condition to handle this, build with
START_APP_UNLESS_SWR defined and it should immediately run the app.
Be careful with that option, as it leaves no way to recover if the
application code never fires a software reset - ie, don't do that unless
you leave PA0 as UPDI or have an HV programmer, unless you want to end up
with a bin of bricked boards gathering dust, marked "Needs HV reprogramming
to use" (like I have).
I have definitely removed the chip from boards and replaced it with a new
one in preference to sorting out HV reprogramming, even though I have a
couple of programmers, somewhere, because there's no mystery to that: Pop
it onto a hotplate at around 210 C, watch it heat up, and as soon as the
solder joints melt, pluck the chip off, and put a new one in it's place,
couple minutes of work once the hotplat is at temperature. (210C is
assuming tin/lead solder. You want something like 25C, minimum, above
liquidus for whatever solder you're using, so more like 250 for classic
lead free, while bismuth-bearing solders can be done with lower
temperatures). Much less work than learning how to use an hv updi
programmer)
—
Reply to this email directly, view it on GitHub<
#851 (comment)>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/A32S4Q7P65Z6JZ3XFFFI2ZLWFFR7RANCNFSM6AAAAAARO75XPE>.
You are receiving this because you authored the thread.Message ID:
***@***.******@***.***>>
—
Reply to this email directly, view it on GitHub
<#851 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW7R43DYZNOZWPU2FSDWFINDPANCNFSM6AAAAAARO75XPE>
.
You are receiving this because you commented.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
Dear Community,
I currently experiment with the Optiboot support in megatinycore and got everything to work after a little fiddling with AVRdude options.
Anyhow, I would finally need a setup where, after PowerOn reset, the uC immedeately runs the application, NOT the bootloader.
The bootloader should then be started on demand, from within the application. This way, I could define in teh application under which circumstands to run the bootloader ( which I need )
I must admit that I do not fully understand WHEN the bootloaders supplied with the MegaTinyCore start. It seems after PowerOn and after software reset.
However, I do believe I need to modify optiboot to:
BUT I do not understand how to do this. I could not really understand the optiboot .c file supplied with MegaTinyCore AND I could not find a doumentation about this topic on the optiboot github page AND the optiboot github page claims there is a new optibootX , but it seems the documentation is not updated ?
Anyhow, any hints towards customizing optiboot, BUILDING it (on windows, unfortunatey) and finally using it, woudl be greatly apprechiated.
Beta Was this translation helpful? Give feedback.
All reactions