Concern (raised by the desktop app team)
The desktop app is expected to go cross-platform (Avalonia) in the future, consuming Core on Linux/macOS as well as Windows. The WiFi-module flash path is not cross-platform in its current form.
FirmwareUpdateService.UpdateWifiModuleAsync runs the WiFi flash by shelling out (via IExternalProcessRunner) to a Windows-only external program:
winc_flash_tool.cmd (a Windows .cmd script — FirmwareUpdateServiceOptions.WifiFlashToolFileName)- which invokes
winc_programmer_uart.exe — Microchip's WINC Programming Tool 2.0.1 [ceebe5f] (Apr 20 2022) (observed in flash logs).
On Linux/macOS there is no .cmd/.exe to run, so WiFi flashing is unavailable. (PIC32 firmware flashing is already managed/native in Core via HID, so it is not affected — this is specific to the WINC/WiFi path.)
Why it's tractable (it's a serial protocol, not raw USB)
The WINC programmer talks to the module over a UART serial bridge: the PIC32 bridges its USB-CDC serial port through to the WINC, and the tool drives the WINC bootloader/programmer over that serial link (handshake → baud change to 500000 → erase/write/read/verify of the 4 Mb WINC SPI flash → Operation completed successfully). System.IO.Ports.SerialPort is cross-platform, so the transport is not the blocker — only the external tool is.
Options (for the desktop team / future work)
- Port Microchip's open-source WINC UART programmer to managed C# (preferred). Microchip ships the
winc_programmer_uart source in the ATWINC15x0 firmware-update package; reimplementing that protocol in Core would make the WiFi flash fully cross-platform and remove the external-process dependency entirely. Likely no reverse-engineering needed.
- Capture the wire protocol to confirm/fill gaps — a serial port monitor, or Wireshark USB capture (usbmon / USBPcap) on the USB-CDC endpoint, to record the exact bridge handshake + flash command framing during a known-good flash, as a reference for the native implementation.
- Keep the external tool as a Windows-only fallback. Core already isolates it behind
IExternalProcessRunner + the WiFi options, so a native flasher could be introduced as an alternate implementation (e.g. an IWincFlasher seam) with the external-tool path retained where the binary is available.
Notes
This is a tracking note, not an immediate blocker — WiFi flashing works today on Windows.
Concern (raised by the desktop app team)
The desktop app is expected to go cross-platform (Avalonia) in the future, consuming Core on Linux/macOS as well as Windows. The WiFi-module flash path is not cross-platform in its current form.
FirmwareUpdateService.UpdateWifiModuleAsyncruns the WiFi flash by shelling out (viaIExternalProcessRunner) to a Windows-only external program:winc_flash_tool.cmd(a Windows.cmdscript —FirmwareUpdateServiceOptions.WifiFlashToolFileName)winc_programmer_uart.exe— Microchip's WINC Programming Tool 2.0.1 [ceebe5f] (Apr 20 2022) (observed in flash logs).On Linux/macOS there is no
.cmd/.exeto run, so WiFi flashing is unavailable. (PIC32 firmware flashing is already managed/native in Core via HID, so it is not affected — this is specific to the WINC/WiFi path.)Why it's tractable (it's a serial protocol, not raw USB)
The WINC programmer talks to the module over a UART serial bridge: the PIC32 bridges its USB-CDC serial port through to the WINC, and the tool drives the WINC bootloader/programmer over that serial link (handshake → baud change to 500000 → erase/write/read/verify of the 4 Mb WINC SPI flash →
Operation completed successfully).System.IO.Ports.SerialPortis cross-platform, so the transport is not the blocker — only the external tool is.Options (for the desktop team / future work)
winc_programmer_uartsource in the ATWINC15x0 firmware-update package; reimplementing that protocol in Core would make the WiFi flash fully cross-platform and remove the external-process dependency entirely. Likely no reverse-engineering needed.IExternalProcessRunner+ the WiFi options, so a native flasher could be introduced as an alternate implementation (e.g. anIWincFlasherseam) with the external-tool path retained where the binary is available.Notes
IExternalProcessRunner,WifiFlashToolFileName,WifiFlashToolArgumentsTemplate, the bridge-activation callback, output-based success verification), so swapping in a native implementation is a contained change.This is a tracking note, not an immediate blocker — WiFi flashing works today on Windows.