Windows on arm64 problem installing xtensa toolchain

Development Platforms
1

Hi,
I’m using a Surface Pro X running Windows on Arm64 (20H2) and running the 32 bit version of VS Code.
I’m trying to compile a ESP8266 project, but the build output just outputs the following message:

Executing task: C:\Users\USERNAME\.platformio\penv\Scripts\platformio.exe run --environment ota <

Processing ota (platform: espressif8266; board: nodemcuv2; framework: arduino)
Tool Manager: Installing platformio/toolchain-xtensa @ ~2.100300.0
Error: Could not find the package with ‘platformio/toolchain-xtensa @ ~2.100300.0’ requirements for your system ‘windows_arm64’
The terminal process “C:\Users\USERNAME\.platformio\penv\Scripts\platformio.exe ‘run’, ‘–environment’, ‘ota’” terminated with exit code: 1.

pio system info gives the following output:

PlatformIO Core 5.2.4
Python 3.9.8-final.0
System Type windows_arm64
Platform Windows-10
File System Encoding utf-8
Locale Encoding cp1252
PlatformIO Core Directory C:\Users\cnienhaus.platformio
PlatformIO Core Executable platformio.exe
Python Executable C:\Users\cnienhaus.platformio\penv\Scripts\python.exe
Global Libraries 0
Development Platforms 1
Tools & Toolchains 1

It seems like platformio cannot find the right toolchain for windows_arm64.
Weird thing is that everything worked perfectly fine yesterday.

Does anyone know how to solve this issue?
Is it maybe possible to force platformio to use the windows_x86 platform through emulation?

Thanks for any help

2

Correct, no such package is uploaded, as listed in PlatformIO Registry.

I also don’t know of any easily downloadable xtensa-gcc package for native Windows ARM64. Distributors like these only have x86 and x86_64 Windows.

According to Introducing x64 emulation in preview for Windows 10 on ARM PCs to the Windows Insider Program | Windows Insider Blog some sort of emulation is available (?). Can you download + extract the x64 version and confirm whether or not xtensa-lx106-elf-gcc.exe --version runs in a shell without hassle?

3

Sadly, x64 emulation for Windows on Arm is not available (as far as i know, it requires installing a insider build or windows 11, both of which are not a option for me)

Running the x64 version from the given link gives me the following error, indicating that it’s not compatible with my system:

ResourceUnavailable: Program ‘xtensa-lx106-elf-gcc.exe’ failed to run: An error occurred trying to start process ‘C:\Users\USERNAME\Downloads\toolchain-xtensa-windows_amd64-2.100300.210717\bin\xtensa-lx106-elf-gcc.exe’ with working directory ‘C:\Users\USERNAME\Downloads\toolchain-xtensa-windows_amd64-2.100300.210717\bin’. The specified executable is not a valid application for this OS platform.

However, using the x86 version, it seems to work just fine:

xtensa-lx106-elf-gcc.exe (GCC) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

4

That is quite baffling, so there has to be an emulation somehow, for x86, but not x64? Hm.

@ivankravets can you enable windows_arm64 compatibility in all windows_x86 PlatformIO packages to solve this problem?

1 Like
5

Could I ask you to re-test the full building workflow before we enable windows_arm64 for all windows x86 packages?

  1. Unpack this package to %HOME_PATH%/.platformio/packages/toolchain-xtensa
  2. Open toolchain-xtensa/package.json manifest in VSCode, replace:
  "system": [
    "windows_x86"
  ]

with

  "system": [
    "windows_x86",
    "windows_arm64"
  ]
  1. Try building any ESP8266-based project.

Does it work?

6

Only unpacking the package and updating package.json like you suggested does not work (at least not by itself):

Tool Manager: Installing platformio/toolchain-xtensa @ ~2.100300.0
Error: Could not find the package with ‘platformio/toolchain-xtensa @ ~2.100300.0’ requirements for your system ‘windows_arm64’
The terminal process “C:\Users\USERNAME.platformio\penv\Scripts\platformio.exe ‘run’, ‘–environment’, ‘ota’” terminated with exit code: 1.

However, i noticed that on another machine, each package had a .piopm file alongside the package.json. Copying that over from the other machine to mine makes platformio recognise the package just fine, but now it clomplains that ‘tool-esptool’ is missing:

Tool Manager: Installing platformio/framework-arduinoespressif8266 @ ~3.30002.0
Downloading [####################################] 100%
Unpacking [####################################] 100%
Tool Manager: framework-arduinoespressif8266 @ 3.30002.0 has been installed!
Tool Manager: Installing platformio/tool-esptool @ <2
Error: Could not find the package with ‘platformio/tool-esptool @ <2’ requirements for your system ‘windows_arm64’
The terminal process “C:\Users\USERNAME.platformio\penv\Scripts\platformio.exe ‘run’, ‘–environment’, ‘ota’” terminated with exit code: 1.

After repeating the same steps (download the package, copy package.json and .piopm over, and modify package.json to include ‘windows_arm64’) for ‘tool-esptool’, ‘mklittlefs’ and ‘mkspiffs’
, i’m actually able to build the project, and even upload it OTA:

Tool Manager: Installing platformio/tool-esptoolpy @ ~1.30000.0
Downloading [####################################] 100%
Unpacking [####################################] 100%
Tool Manager: tool-esptoolpy @ 1.30000.201119 has been installed!
Tool Manager: Installing platformio/tool-scons @ ~4.40300.0
Downloading [####################################] 100%
Unpacking [####################################] 100%
Tool Manager: tool-scons @ 4.40300.1 has been installed!
Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: https:// docs.platformio. org/page/boards/espressif8266/nodemcuv2.html
PLATFORM: Espressif 8266 (3.2.0) > NodeMCU 1.0 (ESP-12E Module)
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
PACKAGES:
– framework-arduinoespressif8266 3.30002.0 (3.0.2)
– tool-esptool 1.413.0 (4.13)
– tool-esptoolpy 1.30000.201119 (3.0.0)
– toolchain-xtensa 2.100300.210717 (10.3.0)
LDF: Library Dependency Finder → https:// bit. ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Library Manager: Installing z3t0/IRremote @ ^3.5.1
Downloading [####################################] 100%
Unpacking [####################################] 100%
Library Manager: IRremote @ 3.5.1 has been installed!
Found 36 compatible libraries
Scanning dependencies…
Dependency Graph
|-- IRremote 3.5.1
|-- ESP8266WebServer 1.0
| |-- ESP8266WiFi 1.0
|-- ESP8266WiFi 1.0
|-- LittleFS 0.1.0
|-- ArduinoOTA 1.0
| |-- ESP8266WiFi 1.0
| |-- ESP8266mDNS 1.2
| | |-- ESP8266WiFi 1.0
|-- ESP8266mDNS 1.2
Building in release mode
Compiling .pio\build\ota\src\main.cpp.o
…
Archiving .pio\build\ota\libFrameworkArduino.a
Linking .pio\build\ota\firmware.elf
Retrieving maximum program size .pio\build\ota\firmware.elf
Checking size .pio\build\ota\firmware.elf
Advanced Memory Usage is available via “PlatformIO Home > Project Inspect”
RAM: [==== ] 37.5% (used 30760 bytes from 81920 bytes)
Flash: [=== ] 34.8% (used 363936 bytes from 1044464 bytes)
Configuring upload protocol…
AVAILABLE: espota, esptool
CURRENT: upload_protocol = espota
Uploading .pio\build\ota\firmware.bin
13:57:46 [DEBUG]: Options: {‘esp_ip’: ‘***’, ‘host_ip’: ‘0.0.0.0’, ‘esp_port’: 8266, ‘host_port’: 11671, ‘auth’: ‘’, ‘image’: ‘.pio\build\ota\firmware.bin’, ‘spiffs’: False, ‘debug’: True, ‘progress’: True}
13:57:46 [INFO]: Starting on 0.0.0.0:11671
13:57:46 [INFO]: Upload size: 368096
13:57:46 [INFO]: Sending invitation to: ***
13:57:46 [INFO]: Waiting for device…
Uploading: [============================================================] 100% Done…
13:57:52 [INFO]: Waiting for result…
13:57:53 [INFO]: Result: OK

So it seems like everything is working perfectly fine using the tools for windows_x86 on arm64.

7

Is there a setting that can be changed so all packages that don’t have native arm64 builds run under x64 emulation?
x64 emulation has been available for Windows 11 on the Pro X since November 2021.

Having to manually modify the platform.json and copy files from another host for every package used in a project is a hassle, especially when it doesn’t work.

8

tbh, thinking about this a bit, it would make sense to use x86 as a fallback for ALL Windows platforms, since every Windows version should support it either natively or via emulation.

basically check if the target can run x64, and if it can’t fallback to x86