update micronucleus #465
Comments
This comment has been minimized.
This comment has been minimized.
|
I took the version from what appeared to be the most recent official digispark package - I would love to get a newer version, are there any prebuilt packages to use, or do I need to get a build environment set up to compile it? |
|
To expand on that - I've seen that repo, but I am not familiar with the process of compiling for desktop computers, only microcontrollers. That's more or less what we got to last time it came up - well, great, there's a new version, but it's source code, and we need binaries for multiple platforms, and I don't know how to get there from here. |
|
You are write, I was on the MC side. On Linux (and may be other OS?) there is no problem to rebuild the commandline-tools with the sources on https://github.com/micronucleus/micronucleus/tree/master/commandline as desribed in #442 |
|
That would explain it. I don't think there are binary releases, I've just been building from source as needed. I have the binaries for the Linux command line and the default bootloader if that helps; I could probably get the other bootloaders & Mac binary without too much difficulty also. |
|
Hm... not sure what to say about this. This is the kind of clusterf* you get into when people start making rogue forks. AFAIR the commandline tool needs MINGW32 to compile under windows due to a dependency on an old version of libusb. That is something that could be fixed, but it takes time. What would actually be preferrable is to clean up the micronucleus reposititory and add CI/CD so there are precompiled releases.
Which did you mean exactly? Maybe I have answered the same questions some years ago :) |
|
Year, therfore I didn't make a fork, only put some code together, to make it more clear... I hope ;-) I think, Spence wants to have a repository, which could generate a new build for each release, automated. On Linux I needn't to fix or use an old version of libusb. With installing libusb-dev and mikrocontroller.net is always my preferred source for solutions - and at the end there was clearly descibed, what to do to compile on (for) Windows. And Google found it because of the stuff, you put there, years ago ;-) |
|
I did not know until just now that there was any work going on in the micronucleus official repo! I looked in master - it was a ghost town (I'm used to the (commit to master, branch releases off of that) rather than doing work in branches that you won't immediately see, I'm sad to see that we've made different decisions on the MCUSR handling. Honestly, I've turned against preserving MCUSR entirely; i'm going to be lobbying hard to clear it whenever we go to the app, stashing it's contents into GPIOR0 and clearly and vigorously documenting that, because otherwise, you really can't guarantee that you honor the requested entry conditions.... and relying on people in Arduino land to check MCUSR? You're just deluding yourself if you think even 1% of them will. IMO one of ideals of a good bootloader is that - barring self programming by the app to overwrite the bootloader on parts where it's not restricted to boot section, of course - the only thing that the application shuold ever be able to do that has anything to do with the bootloader is confirm that the bootloader is there (by reading the flash) and enter the bootloader, either from it's start, by resetting, or (in the case of that thing to allow write from app on parts that don't allow that), via a designated entry point. A poorly written app should not be able to cause the bootloader to not honor it's entry conditions. |
|
The reason that none of my work was ever contributed back to @ArminJo (who I thought was the closest thing to someone who had taken over development of what I thought was the abandoned project, hence why I started from his code) was that after making hash of the build directory (this was after the hdd failure, so it's backed up in multiple places, I then got pulled away onto a few other more pressing matters, and I need to get DxCore and megaTinyCore to a state where people aren't screaming quite so loudly about their deficiencies - objectively, those are probably a more important thing for me to work on, even though micronucleus is fun). I've actually got two new pieces of hardware for IMO the most obvious candidates for micronucleusing among the Classic tinyAVR parts, because I felt like they deserved to have micronucleus... (though I'm getting like another 12+ other new designs in the same batch, so these won't be processed immediately,) plus gimped tiny841 micronucleus boards (it's like the Wattuino one, electrically... but built around the SOIC-14 package, so it cant compete on size, as I didn't want to steal anyone's thunder... but I couldn't seem to DIY one that worked, was like hrrrumph, it's just gotta be the lousy geometry of the wires, a custome PCB will work for sure.... And as I had already drawn something that was sssoooOOOOooo close, I figured I might as well do it. Not sure what my approach going forward is going to be regarding the bootloader itself (I definitely intend to generate a large number of versions of the bootloader for each part, to cover any plausibly useful entry condition, on every part. Azzy cores tend to try to expose every conceivably useful option |
|
And finally - as I've alluded to wanting to do, one day I hope to say a prayer to the lord of the AVR architecture, and armed with a sturdy laptop, clear screen, pure heart, and a copy of the bible ( http://ww1.microchip.com/downloads/en/DeviceDoc/AVR-Instruction-Set-Manual-DS40002198A.pdf ), sequester myself in my room for a some days, and port VUSB to AVRxt. From there, making the rest of the micronuclues bootloader work on the new parts would be a cake walk ((hell then it could also be a "real" bootloader, without having to fiddle with vector tables! Not that I don't think that's part of the fun...). Plus we could run them all at 20 MHz... a ATtiny3217 USB would be pretty sweet... Further beyond, once the code worked on tinyAVR, you'd have it done for the Dx-series as well (no differences in timing), just would need workaround to allow the larger flash (they can go faster than 20, but don't have to) - could use the MVIO o get rid of the need for the zener diodes (Dx series is full speed range over full voltage range - I think core is running at same voltage no matter what the input voltage is, which I don't think was how older AVRs worked). Lot of really awesome things could be made possible.... It's an exciting thing to dream of, but I have more pressing things to attend to... |
|
But no matter what. somehow we need to get binary packages of a current version of micronucleus for all the relevant OS's... we don't need anything fancy like continuous delivery, but we need something reasonably recent that works with the current version of the firmware, since Arduino board packages (whcih is how like 99% of people install "board packages" now) is needed to make that experience work out... If that means someone like @pcfreak1201 building it when something big happens, directing me to the files, and me swapping out the micronucleus exe with the new one, so be it... heck, it might only need to be done every time a board that broke compatibility suddenly became supported or something.... We don't need perfectly up to date micronucleus tool.... just something recent enough to be usable without problems... |
|
Well, I lost the track to Windows since XP, so it is more likely @sanbeg or @cpldcpu who will build EXEs ;-) |
We may be thinking about the opposite thing. I don't think it's necessary to set up sources for the 5 year old binaries; but rather, a way to automatically set up binaries for the current sources. For the current bootloader, the protocol isn't the same as the 2.04a version. So if you buy one of these boards now and decide to update your bootloader to a recent release, you also need to overwrite the command line tool from the core with the recent one. I took a quick look through the core, and I wasn't quite able to track down where the core is configured to use 2.04a; so they only way I was able to make it work was by copying in the tool, then replacing |
It's defined in the package index's Here: |
|
And - the reason I use that version was that that was the only version of binaries that I was able to find! I was unaware that there even WAS an updated version of those tools... and the people I was talking to and who were driving this project forward were ALSO using those old versions of the tools, because that's the version that was there... |
|
I was not at all suggesting that we start some new system for hosting ancient binaries, but rather - if there's a new version, and people who know how to build it, can we please get some builds made and start using them? Like, a way to automatically build them is lovely, but let's not let the perfect be the enemy of the good... just building a recent snapshot that we can pull in with an Arduino core and hosting them somewhere (github?) would be better than anyone has done since, well, since 2.04a!!! |
|
Yes, VUSB is one of several AVR bitbang USB implementations. Was developed quite a while ago. My understanding was that it's the best out of the lot, and seems to be what all the AVR-based USB devices using AVR's that don't have "real" USB are built on. The company that does it is still around, though I don't think they're actively developing it. I was considering buying a commercial license so I could keep my cards close to my vest when I finally dig out of enough other projects to get to try to port it to the new AVRs (I did look through the assembly - it's all hand-tuned assembly - and it definitely looked doable, and I love working that close to the metal... In any event. the whole reason this came up, though is that the micronucleus upload tool is clearly too old, as there are lots of bootloaders living on boards in the wild that these upload tool binaries won't upload to. Arduino cores live in a world of board manager, so "just build micronucleus yourself" does not fly, heh... and I don't know how to program devices with more than 128k of program memory (I was born without an EIND register you see....) (actually, that's not true - a few years ago, we needed a dual booting bootloader for an arduino mega2560, but it had to still work like a normal mega too, but also support another protocol on another serial port under certain conditions.... Luckily the Arduino bootloader was grossly bloated with some "monitor" thing nobody ever used. Without that, I had acres of space after the end of the bootloader, and stuck this other bootloader back there. Actually though, I think my poor understanding at the time of how that was handled contributed to some difficulties getting to it (though we worked around that easy enough... |
|
Yes, the tools (binaries) are too old, but not the protocol. So we have to clean up the source "HAL" to get rid of unsupported/obsolete libraries as cpldcu mentioned:
But as I said, Linux doesn't look like the problem ;-) |
|
So not sure how I missed this until last night, but it looks like micronucleus does include a prebuilt windows binary mixed in with the sources. So with that I have mac, windows & linux 64; the only one I don't have yet is 32 bit linux. I've gathered up my work in progess @ https://github.com/sanbeg/MicronucleusArduino So far I've only tested on Linux, but I can do some more testing then clean and package that. |
|
Oh! That's wonderful... And wait, the whole purpose of launcher is just to rewrite the arguments passed to micronucleus executable? Couldn't we just do that in platform.txt and do away with it entirely? Something like... (with the path adjusted to point to micronucleus instead of launcher?) |
|
Cool! Any yes, removing the launcher would be nice. But the Digispark hasn't a reset button! I also had a quick search for getting the actual libusb environment running for windows at my linux. And nope, I won't go down this rabbit hole. To start with quite well supported souces I think https://github.com/msys2 (only for LibUSB support on Windows!) looks very "promising"... |
|
The official digispark? Yeah that one may not have a reset button. 99% of the clones do, and don't come with reset disabled... so if we do need to keep the script for launcher, the text printed should reflect the fact that the correct course of action might be to reset it, it might be to plug it in, it might be to plug it in with a specific pin held low, and so on..... And, somehow looking at it now, i see that his launcher script does indeed say plug in or reset.... how did I not see that last time, lol |
Yeah, I think digistump designed it to pass through to avrdude, or to translate if you speci
That should work.
I think the message in Digistump's binary is specific for their digisparks, which I believe had the reset pin disabled. I reworded that in my script because I usually breadboard a reset button onto the clones I've been using. Ideally, micronucleus could emit the message at the right time, but if it doesn't I don't think the launcher script is a terrible approach. We could also simplify it if we don't need to translate avrdude options and either pass through its options directly, or just hard code most options, and just pass in the filename. I actually hadn't noticed the issue with the data coming in chunks. If that's due to the binary buffering the output incorrectly, it should go away if we move to a script. |
|
Well, that was dumb. After going back up the thread here, it turns out building |
|
@stonehippo Would you mind specifying: |
|
And, I would disagree that it was "dumb" - if people either suffered in silence, or built it themselves, we'd never end up with an automatically installable binary for board manager installation! |
|
I've got the tool compiling under Msys2/MinGW64, but it won't compile statically due to a lib incompatibility. Can't see why, yet, but will keep at it. |
|
@SpenceKonde |
|
Siiiiiiick! Need to finish DxCore 1.3.1 and get that released which I hope can happen today/tomorrow (test that changing TCA PORTMUX correctly moves analogWrite pins and that the TCD PWM pins act like the PWM pins on the ATtiny x7 of ATTinyCore now, and clean up variants for the TCA change, propagate flash-write changes from DA to DB and make at least one AVR128DB board I have run and test Opamp.h on it).and then can finally come back to ATTinyCore |
|
You just had to delete the old file didn't you? Good job - now nobody can install ATTinyCore |
|
SpenceKonde/ReleaseScripts@19300de#diff-dba3a4c259e313a72ba4b704f3db5319f26fac51bde77dfa545d5acd993b7754 2.0a4 windows (same version) rehosted to restore functionality. |
|
Good Morning! Sorry |
I just noticed that the PR to fix the mirconucleus issue with the "please plug in" message being buffered was rejected. So it looks like we'll still need a launcher script to emit that message. micronucleus/micronucleus#193 |
|
Oh, I found a clean copy - but I only had one copy of that one. Like 4 copies of the one from the official digispark repo. wait, you were using the digispark version? But it's not the same! one of the files - I think the .inf - is slightly different. I was under the impression that yours fixed something, which is why I used yours for windows instead of the old digispark one. But I think it was relating to the digispark USB libraries, I think the CDC one, but that one never worked for me no matter what I did! (tried both installs many times. ) Were you ever able to make the libraries work? I never was able to make any USB libraries work, which is precisely why I don't include those libraries with ATTinyCore. I got some help from someone on FB - but then life got crazy. What I was going to do is 1) geta known working hex file and from there, I should be able to work on the driver issue until I have it working on my test systems. Then, I could work on fixing the libraries so I could build my own working ones (i'd have the advantage of being able to examine the hex files of a working and non-working build, too. Maybe I'd find that if I went back enough compiler versions, finally it would work, and I'd see what the difference was and be able to prevent it from happening. (and I could dump a .lst of both versions too).. |
|
@SpenceKonde I never did a fresh install on windows for the micronucleus USB driver in the last year. Maybe I should test it again. |
Please let me know how to set it up if you manage this - I have always really wanted to be able to make thee into USB devices! It would open so many doors! |
And it will have you pulling out your hair. V-USB is by no means robust. Even micronucleus isn't as robust as it could be, and that's a lot easier to do when you have 100% control of the CPU and interrupts. For example I found a bug in Tim's OSCCAL tuning code. It seems the USB hubs he tested on were more like a USB switch and didn't broadcast traffic to every port on the hub after they were enumerated. On the PC I was using, with a common Intel chipset USB EHCI, the interrupt IN tokens for my low-speed mouse get broadcast to every port on the same hub, which was sometimes throwing off the tuning. Then on top of the software hacks, you have the common hardware hack of running the AVR at 5V, and clipping the D+/D- signals with zeners. Even if you get the "right" zeners, you've reduced your signal margins since the host outputs 3V3 (> 2.7V from what I recall of the USB spec), and the AVR thinks 5V is high. VIH for most AVRs is between 2.6V and 2.8V with 5V power. If you run the AVR at 3V3, VIH is between 1.7 and 1.9V, making things much easier. If you want to make a USB project that other people can build and use on Windows, Linux, MACs on their various hardware platforms, it's WAY easier with a MCU that has a hardware USB SIE. For around $1 you can get an ARM Cortex-M MCU with a full-speed USB peripheral, or for less than $3 you can get a tube of 10 8051-based CH551G MCUs. |
|
BLOODY HELL! There are at least three distinct versions of each of the micronucleus tool files, with the same name, which differ by 20-50 bytes in size and have a different SHA hash. Sorting that fucked up mess out is what's between here and 1.5.0. Should be ready tonight... and they are all getting repacked, WITH A UNIQUE NAME I just went through generating SHA-256 hashes and file sizes for the 7 archives. because they didn't match what was in the archive. Then I looked at what I had on the webserver.... they're all different too! It looks like every place that the 7 packages are located, they were compressed in a slightly different way, yielding an ever-so-slightly different archive, and because the size is almost identical and the names are the same, |
|
And the digiusb drivers for windows are missing from the archives too - we only have the digiserial (CDC) drivers, which it has been clearly established do not work on post-XP windows or recent versions of the linux kernel... instead of the DigiUSB drivers they were meant to replace, but which still work whereas the CDC ones do not.... I don't know why we have the drivers that are known to not work, and don't have the drivers that do - I generally try for the other way around.... |
|
Okay, 1.5.0 is getting: For all windows: Repacked micronucleus binaries, with the files related to DigiUSB and DigiX, and a post_install.bat file. We know that Arduino will not run that file, but it will print a warning mentioning that - specifically, mentioning the file path. So an enterprising user could track it down and run it to install the drivers. My interpretation of the doom gloom and begging for salvation on other forums about the serial drivers is that: However, all is not lost, as there are widespread reports of DigiUSB continuing to work fine. Provided that can be confirmed, this leaves us in a worse place than if we had CDC, by far - but compared to having neither of them, it is greatly preferable; while it requires custom software, such software can be written in python and examples appear to be available. My interpretation of the body of the files is that DigiX is related to DigiCDC. |
|
gives users a path to follow to trace down the drivers. Maybe in future version I could even split the drivers off into an extra dependancy, so it could look like: |
|
Raarrrrrgghhh! Okay! it's done! |
|
Oh man, thanks for all of this @SpenceKonde! Looking forward to trying out 1.5.0 from a RPi (upgrade from 1.4 worked smoothly). Sorry I couldn't get the damn binaries all the way there for you. |
|
@SpenceKonde while adding post_install.{bat,sh} support to Arduino CLI, the point was raised by Matthijs that this is really a pointless restriction, since the user is just about to run arbitrary executables from the platform anyway. So post install script now works for 3rd party boards platforms when the user is using Arduino CLI or Arduino Pro IDE. This will also be applied to Arduino IDE as soon as the Boards Manager business code in the IDE code base is removed and replaced with a call to Arduino CLI. That process has gradually been happening with all the non-GUI code in the IDE. |
|
Wonderful news!
…____________
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, Feb 27, 2021, 01:22 per1234 ***@***.***> wrote:
@SpenceKonde <https://github.com/SpenceKonde> while adding
post_install.{bat,sh} support to Arduino CLI, the point was raised by
Matthijs that this is really a pointless restriction, since the user is
just about to run arbitrary executables from the platform anyway. So post
install script now works for 3rd party boards platforms when the user is
using Arduino CLI or Arduino Pro IDE.
This will also be applied to Arduino IDE as soon as the Boards Manager
business code in the IDE code base is removed and replaced with a call to
Arduino CLI. That process has gradually been happening with all the non-GUI
code in the IDE.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#465 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW6RTNUCV4LXMAB4MXLTBCFQ7ANCNFSM4SNYOAIA>
.
|
|
It looks like those MN builds are still using Tim's osccal tuning code. As I mentioned above, it has a subtle bug that will sometimes choose a bad OSCCAL value if there's another low-speed device such as a keyboard or mouse on the same root hub. It is likely to be quite frustrating to users who encounter it, as it will seem almost random since it is only a problem when one of the first couple frames is non-empty. Tim helped review and optimize my new tuning code, which in addition to fixing the bug is smaller than Tim's original asm version. AFAIK the version of MN used by Eric on the DigiSpark didn't have this bug. I think that version used Christian's tuning code, which doesn't have this bug. I even think Christian's osctune.h code may be a better choice for a bootloader than my asm OSCCAL tuner. For a USB library, my code is better because it doesn't tie up timer0. |
|
Hi Ralph, indeed, we should include your excellent code. Can you submit a pull request to the MN repository? Btw, the issue with the hub was fixed at some time, but I had to remove the code again, because of some timing issues with windows 10 afair. So far, there wwas not really a bug report regarding USB hubs that forward all traffic. It may be that they are not that widely spread. |
I just opened a discussion about it.
I think you are underestimating the extent of the bug. If you look back our email communications from May of 2014, I was having problems with OSCCAL tuning back then, but wasn't able to nail down the specifics of the bug. It's only last year after getting a better understanding of the protocol and having a good logic analyzer and scope that I was able to confirm the bug. To identify the bug I had to:
Since the bug is intermittent (around 10-20% of the time from my experiments), many people that encountered it may have been OK with the simple unplug and re-connect "solution". |
|
What I never understood is why MN needs to re-tune every time, rather than saving the correct tuning value... could even achieve that with one of the "updater" type sketches. You've got all the flash you need to write a really careful funer, cause you're gonna delete it, then it rewrites the last page of the flash (where the bootloader resides), adding the tuning value it determined, and you upload another sketch over it, and every time it starts, MN uses that saved OSCCAL value... As long as it was being used indoors from a USB port that was outputting ~5v,, there's like a 0.3v and 10 degree C window it's gotta work in... I don;t think the dependence on T or V is that strong, is it? why would we have to re-tune it? having to re-tune every start makes the whole thing way more demanding, because it means the tuner needs to be built for size and speed since it is eating up space that the sketch could be occupying and needs to be able to tune off of USB and right away be able to communicate over USB. |
|
I do exactly that with picoboot-lib (calibrate once and then self-modify
the bootloader code with the OSCCAL value). With a 8N1 UART, you have
a +5.88%/-6.25% margin of error for timing.
For the T85, it looks like there's a 0.6% frequency difference from 15C to
30C. The total margin of error for V-USB 16.5Mhz is +/-1.5% at best.. I
suspect there may even be hubs out there that don't fully comply with the
spec and require device timing to be within 0.5%, since that's the
requirement for full-speed (12Mbps). OSCCAL steps on the t85 in the
16.5MHz range are around 0.7-1%, limiting it's tuning ability.
I think a one-time calibration may have the most merit for AVRs with better
RC oscillators like the t84A. The frequency drift from 15-30C is only
about 0.3%, and the frequency change per OSCCAL step is about 0.5%. My
tuning code is limited to 5 SOFs, and can't guarantee the best OSCCAL value
is chosen. A longer-running calibration done the first time the bootloader
is run, could sample dozens of SOFs to pick precisely the best OSCCAL
value. The reduction in the bootloader code size is ~50 bytes, making it
not a high priority target. When MN merges most of my asm branch code, the
reduction in bootloader flash size should be over 100 bytes.
edit: the size reduction is actually over 200 bytes.
…On Sat, Feb 27, 2021 at 4:13 PM Spence Konde (aka Dr. Azzy) < ***@***.***> wrote:
What I never understood is why MN needs to re-tune every time, rather than
saving the correct tuning value... could even achieve that with one of the
"updater" type sketches. You've got all the flash you need to write a
really careful funer, cause you're gonna delete it, then it rewrites the
last page of the flash (where the bootloader resides), adding the tuning
value it determined, and you upload another sketch over it, and every time
it starts, MN uses that saved OSCCAL value... As long as it was being used
indoors from a USB port that was outputting ~5v,, there's like a 0.3v and
10 degree C window it's gotta work in... I don;t think the dependence on T
or V is that strong, is it? why would we have to re-tune it? having to
re-tune every start makes the whole thing way more demanding, because it
means the tuner needs to be built for size and speed since it is eating up
space that the sketch could be occupying and needs to be able to tune off
of USB and right away be able to communicate over USB.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#465 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKNZ6V7FF2FDS3AVAYLKTTTBFG6NANCNFSM4SNYOAIA>
.
|
|
Have you checked if this fixes the bug? As stated there, it was in the codebase for a long time, but caused MN to fail when Win 10 came out. That's why I removed it, because few people actually use USB 1.1 hubs and my expectation was that this would decline further over time. Your new solution is much better because it does not extend the osccal duration so it should still work with Windows 10. So if we can include that everything should be fine. @SpenceKonde Well, you can activate saving of oscall in the source. The oscillator frequency changes with temperature and voltage (there can be quite some different in actual USB voltage) and you never know how marginal you are if you only save the value once. To do this properly you would have to find a way to define when this perfact osccal value is found and only save it then. Surely doable but it's quite some work to do this properly, it may add complexity to the usability of micronucleus and we may encounter new bugs along the way. |
The issue is not limited to USB 1.1 hubs. I think I mentioned in one of the MN issues that I debugged the issue using a PC with an Intel chipset and USB 2.0 high-speed (i.e. 480Mbps) EHCI hubs. It only happens when there is traffic for a 2nd low-speed device on the same hub. In my case it was when I had my mouse plugged into the same hub. Since some ports are routed to the back of the PC case and some are routed to the front, it took some time to realize that the intermittent enumeration problems were primarily happening with certain ports. Years ago I was using genuine DigiSpark devices (with RSTDSBL programmed), and therefore had to unplug and re-connect the digispark to force a re-enumeration. I now know there was a 50/50 chance I'd plug it into a port on the same hub as my mouse. So this was a very tricky bug to track down, taking much more work than your typical MN and/or V-USB user is going to bother with. USB hubs isolate traffic for different speed devices, so if a device running MN is plugged into the same port as a high-speed flash drive, the AVR will never see any of that traffic. In fact, if you could count on there being no other USB traffic on the port, you could eliminate the code in V-USB for handling the 7-bit USB device address. As for Win 10, someone else will have to test that. I've tested on Win7 & Linux. I had Win10 installed on a machine a few years ago, but the motherboard died. When Win10 refused to run on the replacement motherboard (something to do with the license key), I just wiped the disk and installed Ubuntu. |
The micronucleus bootloader is bundled with a command line utility. Although this command has backwards compatibility to allow the command to work with older bootloaders, it doesn't have forwards compatibility, and thus will refuse to work with newer bootloaders.
It appears that ATTinyCore bundles an old alpha of this command from 2015, which is no longer listed in the release page https://github.com/micronucleus/micronucleus/tags (IIRC, the same version that was used by the long since unmaintained Digistump core).
When trying to flash a Digispark clone with an updated bootloader, I get this error:
Although may cheap clones still use very outdated bootloaders which will work with this old tool, an updated tool would work with both old and new bootloaders.
The text was updated successfully, but these errors were encountered: