v0.8.0 — firmware bug fixes

What's new

Flashable build from 7483bf3 (merged PR #1 bug fixes), verified on hardware.

Fixes included

• Loop cache / VU meter, USB volume rollback, incomplete SONG_COMMIT
• eMMC capacity / CRC / SPIM alignment
• Boot speaker unmute, format/playlist, USB desync recovery
• SONG_BLOCK during CMD25, SONG_SWAP rollback, prefetch underflow, CODEC_DIAG WDT

Binary

• marisko.bin (73020 bytes)
• SHA256: e4067cfa5037d1ca467137ae12e643065ceaff8cfe3994e0e71d8b6bc324e672

Flash with rome flash or the solderless utility. Same Rome version is fine.

v0.7.1

Reverts v0.7.0's Bluetooth scan/pair feature. Despite several rounds of real-hardware fixes (gesture ergonomics, a stuttering regression fix, a stop-inquiry call, and finally a full inquiry-result RX/connect path), pairing to a real device never actually completed and the root cause was never isolated without a logic-analyzer capture. Reverted to the last known-good state rather than continuing to guess. See AGENTS.md in the repo for the accumulated findings if this is revisited.

v0.7.0

Bluetooth scan/pair trigger.

Hold vol+ and vol- together for ~2s (per TE's own user guide) to make the
onboard Bluetooth module pairable and start scanning for nearby speakers/
headphones. Track LEDs blink for a few seconds as feedback while it's
running.

Auto-reconnect on power-up is untouched -- this only adds the manual
trigger alongside it.

How it works: the nRF52840 has no antenna, so Bluetooth on the SP-1 is a
separate Infineon chip talking over UART. This release wires up that UART
for the first time and drives the module's existing stock software with
its own standard command protocol -- nothing on the Bluetooth chip itself
is modified or reflashed.

Known limitation, being upfront about it: this has NOT been confirmed on
real hardware yet. The commands sent are the standard ones documented
publicly for this exact chip family, but this specific unit hasn't been
tested. If holding vol+/vol- doesn't do anything, that's useful
information for refining it further.

v0.6.4

Gate effect now supports holding multiple track buttons at once (with function held) -- all held stems gate together in sync.

v0.6.3

Fix: releasing the track button right after a gate effect (function still held) was immediately re-arming the power-off countdown -- felt like an unwanted auto-shutdown. Now the whole function hold stays disarmed for power-off once it's been used for a gate, until you fully release and press function again.

v0.6.2

Fix: holding function+track for the gate effect was also triggering main()'s power-off hold (same button, read independently), showing the shutdown LED-fill animation instead of gating. Gate gesture now suppresses that.

v0.6.1

Gate effect: hold function + hold a track button to gate that stem (basic mode's only effect per the TE guide). Stops the instant either releases.

v0.6.0 — seamless loop + 250ms loop fix

What changed

Seamless looping (fixes the audible ~0.5s gap at the loop seam).

Previously the loop re-read the loop region off the eMMC on every pass. At the
wrap, a blocking CMD18 refill had to finish before the first loop block was
available — and a 94-block loop exceeds the 64-block prefetch window — so the
feed thread stalled for ~0.5s each pass (audible as a stutter/gap, plus feed
write_fail/recover counters climbing).

Now the whole loop region is cached in RAM once at loop start and every wrap is
served from that cache: the seam is a pure pointer reset with no eMMC access,
so the loop is seamless.

Net-zero RAM. The 96-block loop cache reuses the existing 64-block prefetch
buffer and the 24KB baked-level array (via a union), so RAM usage is unchanged.

Loop behavior

• Fixed 1-second loop base (375 blocks @ 48kHz / 128 frames) with divisors
  {1, 2, 4, 8, 16}; default index-2 setting = 250ms loop.
• Loop is momentary: hold Play to loop, release to stop.
• Volume buttons change the loop divider while looping; rocker re-anchors the
  loop point.

Firmware

• Flash-ready file: marisko.bin (this release asset).

v0.5.0

Battery status.

The SP-1 has a BQ24232 charger IC on P0.21/22/24 and a battery-voltage
divider on AIN4 (an otherwise-unused ADC channel) -- confirmed against
another independent SP-1 firmware project (sp1-tape-looper) reverse-
engineering the same hardware. This release wires that up:

• Tap the function button once while the device is off and plugged into
  power (a brief <600ms press, not a hold) to see the charge level in
  quarters on the track LEDs for ~3 seconds, then it goes back to sleep --
  no full boot happens.
• New USB_CMD_BATTERY (0x12) lets a host tool (rome) read percent/
  charging/USB-present any time the device is awake.

Calibration note: the percent/quarters mapping uses an inherited,
explicitly-uncalibrated raw-ADC range (full anchor measured at rest;
empty is a physics estimate, not a real measured low reading). Treat it
as approximate until refined against a real near-empty reading on this
unit.

v0.4.1

Fixes the boot-on LED fill actually running slower than the shutdown fill.

v0.4.0 fixed a redundant extra animation stacked onto the power-on-from-off
path (that was the "boot takes longer than shutdown" complaint at the time),
but the two "same 3000ms" fills were still drifting apart underneath that.

Root cause: the power-on hold gate paced its 8-LED fill by counting fixed
delay_ms(20) steps -- delay_ms() is a NOP-counting busy-wait explicitly
documented as "not precise", and its real duration depends on CPU clock
state that isn't guaranteed to match between early boot (before USB/codec/
eMMC bring-up) and deep into runtime, where the power-off hold's identical
fill is timed. That fill paces itself from k_uptime_get() (RTC-backed)
elapsed time instead, which is why it was always accurate.

Fixed by pacing the boot-on fill from k_uptime_get() the same way, so both
fills are driven by the same clock and stay in sync.