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.