[pfeerick]

Summary

Closing the simulator while the firmware is still booting can hang Companion. This fixes a deadlock in WasmSimulatorInterface between stop() and the firmware threads.

Cause

• stop() holds m_mutex across simuStop(), which joins the firmware threads.
• Firmware threads read analog inputs through host_simuGetAnalog → getAnalogValue(), which also locked m_mutex. A thread that reads an analog after stop() takes the lock blocks forever, so the join never returns.
• The GUI thread polls simulator->isRunning() in SimulatorWidget::stop(), which takes the same mutex. It blocks there, so the 2s stop timeout never fires and Companion hangs.

It only happens when closing early because the menus task has to finish edgeTxInit() before it can exit, and that reads analogs (throttle/switch checks, splash inactivity check). In steady state the threads exit without another analog read.

Changes

• Store m_analogValues as std::atomic<int16_t>, so getAnalogValue() and setAnalogValue() no longer take m_mutex.
• Close the SDL audio device after simuStop() rather than before, so the firmware audio task cannot be inside SDL_QueueAudio() while the device is closed.

Testing

• Not yet built or run: WAMR could not be fetched in the dev environment. Checked separately that the std::atomic<int16_t>[] member initialiser compiles with -std=c++17.
• To verify: launch the simulator for a colour radio (e.g. TX16S) from Companion and close it while the splash screen is still showing. Companion should no longer hang.

🤖 Generated with Claude Code