In anticipation of the new speaker libraries that are soon to be released, I’ve been experimenting with audio clips. While locally compiling a larger test app for the Time 2 (Emery), I ran into an install issue that I wanted to document in case anyone else hits the same wall when working with heavier media assets.
The Environment:
- OS: Gentoo Linux
- Python: 3.12 (managed via uv)
- SDK: 4.9.148
- App Payload: ~1MB (containing media assets)
The Problem:
When deploying the app via CloudPebble, it installs and runs perfectly in the emulator. However, when building and installing locally via pebble install --emulator emery --logs, the install reliably crashes with a TimeoutError.
Looking at the -vv double-verbose output, the PutBytes transfer starts successfully, but eventually, QEMU stalls out with a hardware warning:
DEBUG:libpebble2.communication:-> PutBytes(command=None, data=PutBytesPut(cookie=1285684441, payload_size=None, payload=857f6d657897a7a6a09b948f939ea2998f…))
qemu stm32: hardware warning: PLL cannot be disabled while it is selected as the system clock.
…
libpebble2.exceptions.TimeoutError
It seems CloudPebble bypasses the virtual serial bottleneck by injecting the .pbw directly into the virtual filesystem. The local pebble-tool, however, pushes the data through QEMU’s emulated serial port.
Because libpebble2 is sending the data over a high-speed local TCP socket, QEMU receives the massive 1MB payload almost instantly. QEMU then tries to feed this into the virtual watch, triggering thousands of virtual hardware interrupts. The emulated STM32 processor gets completely overwhelmed by the interrupt flood, desyncs its internal clock (throwing the PLL cannot be disabled panic), and effectively freezes. The Python script then sits there waiting for an acknowledgement that never comes, eventually throwing a TimeoutError.
Questions & Feature Request for the Devs:
Given how QEMU handles the serial buffer, is there any chance we could get a flag for the local pebble install command (something like --sideload or --direct-inject) that bypasses the serial port and mimics CloudPebble’s direct memory injection?
Alternatively, would simply increasing the libpebble2 timeout thresholds for local emulator targets allow the virtual processor enough time to chew through the interrupt backlog, or does that PLL panic mean the virtual hardware is permanently locked up?
Having a way to test larger, resource-heavy payloads locally without crashing the emulator would be a huge help! Thanks for all the hard work!