OK, I found the cause is a recent change to the expiration time GitHub sets for the token that is used to download a release asset. The expiration is now set for 5 minutes after the initiation of the download. This means that the download is intentionally failed if it takes longer than ~5 minutes (there is apparently some leeway on the enforcement of the expiration).
There is discussion about that here:
This means that whether or not a given release asset fails is dependent on the speed of your Internet connection. My Internet connection is fast enough to download the 142 MB xpack-arm-none-eabi-gcc-9.3.1-1.3-win32-x32.zip file in less than 5 minutes, so the file download succeeds for me. Conversely your Internet connection is just slightly too slow to download the file in time, so it fails for you.
Likewise, my fairly slow Internet connection makes the 574 MB silabs_arduino_core-3.0.0.zst platform archive file of the "Silicon Labs" boards platform's 3.0.0 release take >5 minutes, so this is why installation of that platform fails for me, even though many other people with faster Internet connections have been able to install it without any problem.
The workaround will be to manually download the file using a tool that supports resumption of downloads. The Google Chrome web browser ostensibly does, but I actually haven't had any success when I tried to use it to resume downloads of the file. When I click "Resume" on the failed download, it immediately fails again with a "Site wasn't available" error (if I do it via the menu of the "Downloads" icon on the browser toolbar), or "Failed - Unknown server error. Please try again, or contact the server administrator." (if I do it via Chrome's Downloads page). I believe this is due to the fact that GitHub redirects the initial download URL to a temporary URL that is authenticated with the JWT token, and Chrome isn't smart enough to resume this type of download.
I am able to resume the failed download when I perform the download using using curl.exe --continue-at - --location --remote-name.
I was also able to resume the download using wget --continue.
If you already have a download manager tool that supports resuming these downloads, you should use that to manually download the file. If you don't already have one, I will suggest you use curl as, unlike Wget, this is preinstalled in Windows. I'll provide instructions you can follow to do that:
- Right click the Windows "Start" button.
A context menu will open. - Select "Search" from the menu.
The Windows "Start" menu will open with a search field selected. - Type
windows powershell isein the search field. - Select "Windows PowerShell ISE" from the search results.
A "Windows PowerShell ISE" window will open. - Type the following command in the Windows PowerShell ISE window:
curl.exe --continue-at - --location --output-dir "$Env:LOCALAPPDATA\Arduino15\staging\packages" --remote-name https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/download/v9.3.1-1.3/xpack-arm-none-eabi-gcc-9.3.1-1.3-win32-x32.zip - Press the Enter key.
The file download will now start. - Monitor the progress of the file download. After approximately five minutes have passed, it will exit with a message something like, which indicates that the download was not successful:
curl: (18) end of response with 35384341 bytes missing - Repeat steps 5-7.
The file download will now resume. Something that might be confusing is that the progress indicator only shows the progress during the current download attempt. The lack of a sign of the progress from the previous download attempt makes it seem like it started the download over from scratch rather than resuming. However, you will know it has indeed resumed because the command will print a message something like:** Resuming transfer from byte position 111658240 - Hopefully after the second attempt, the upload will complete, as indicated by the lack of a "
curl: (18) end of response with \_\_\_ bytes missing" message when the command exits. However if it still didn't complete, you can simply repeat steps 5-7 as many times as it takes for the file to download completely.
After that, try installing the "STM32 MCU based boards" platform via the Arduino IDE Boards Manager again, just as you did before. Hopefully this time it will be successful, as it will use the existing file you downloaded using curl instead of attempting to download it from the Internet. It may still need to download some additional files from the Internet, but they are all significantly smaller than the xpack-arm-none-eabi-gcc-9.3.1-1.3-win32-x32.zip file you had trouble with, so hopefully Boards Manager will be able to download those.
After that, you can repeat the same procedure for the "esp32" boards platform. You only need to change the URL in the command at step 5 to the URL of the download that failed:
curl.exe --continue-at - --location --output-dir "$Env:LOCALAPPDATA\Arduino15\staging\packages" --remote-name https://github.com/espressif/crosstool-NG/releases/download/esp-14.2.0_20241119/xtensa-esp-elf-14.2.0_20241119-i686-w64-mingw32.zip
However, in this case there are actually multiple very large files that must be downloaded, so you will likely find that Boards Manager installation still fails even after you manually download that xtensa-esp-elf-14.2.0_20241119-i686-w64-mingw32.zip file, and you will also need to manually download the additional files that Boards Manager fails at. If you have any questions or problems with that, just let us know and we'll provide further assistance.
There is a feature request to add support to Arduino IDE for resuming file downloads here:
That would mitigate the problem as, even though the first attempt at the installation might still fail, it would finally succeed after subsequent attempts as the file was downloaded incrementally.