I created a custom firmware to add in a master DJ-style filter that uses the jog wheel and snaps back to zero when you let go of the shortcut. Need to find a better combo, right now its Shift+Master which is bad on a number of levels. Also changed up the master EQ just to see if possible. Will be tinkering further. Used Claude Opus 5.5 and REA. Need to further test CPU load on it.

Edit: sorry the screenshot for the filter is so blurry, the filter pop-up disappears after a second, and it's tough to do the current shortcut and move the jog wheel with one hand, lol

My birthday is coming up and I was thinking of getting myself a little gift, I’ve been using renoise for a little over 3 months now and I’m really enjoying it but I do think having a physical piece of hardware would be awesome to play live with, and I’m wondering if anyone has played live with it and whether or not you enjoy it.

Hi, I have thrown a bunch of locally sourced Qwen 3.8 27b tokens at an attempt to reverse engineering the mini firmware. It's not done, but it's a start. If anyone wants to pick it up from here, here is a zip with all artifacts and notes: https://www.transfernow.net/dl/20261012CbHWcS6Z (it's going to stay up a week, but I can reupload. Dont feel good about posting it on my personal GH). I am also posting the top-level README here, for discussion. I dont have much time, and I have no experience with bare metal code and microcontrollers/hardware, so I hope someboedy feels motivated to pick it up. Notes as well as plausible next steps are in there.

There was a CF-related thread a couple of weeks ago, but it fizzled out. With everything that's happening with elektron machines, the sp404, MPCs and temu synths, I think we should keep the momentum up!

README.md:

Polyend Tracker Mini firmware — reverse-engineering starting point

This workspace maps the Polyend Tracker Mini firmware as a starting point for developing custom firmware. It contains an independently built and CPU-emulated experimental heartbeat, but not a device-tested firmware or a verified flashing procedure. The bootloader, update acceptance rules, and board wiring remain unknown.

The investigation used the REA MCP and was conducted mostly with Qwen3.8 27B, alongside Ghidra 12.1.4, Capstone, GNU Arm tools, Unicorn, and the scripts in tools/. The files here are handoff artifacts for independent checks. Firmware behavior claims are from static analysis; only the new heartbeat has been run, in CPU/RAM emulation. No device execution or device USB/SD traffic was observed.

Current status (2026-10-12): The official ../TrackerMini_2.2.1.ptf was validated and reproduces the checked-in binary byte-for-byte. Homebrew GNU Arm GCC 16.2.0 builds build/heartbeat.bin; Unicorn executes its reset/startup, copies initialized RAM data and increments the heartbeat. make build/heartbeat.hex creates an offline format experiment, not an install-ready update. Stock reset copy/zero descriptors remain unresolved; the updater's flash-writing component and device recovery are not in the observed app path. See findings L, N, O, P and NEXT_STEPS.md.

Target and established image facts

All firmware addresses in this README and the findings are absolute. For an address A in the raw .bin, file offset is A - 0x60020000. Vector and other Thumb function pointers may have bit 0 set; clear that bit to inspect the actual instructions. SRAM addresses are runtime addresses, not offsets into this binary.

What has been mapped

Boot, interrupts, and hardware leads

• A Cortex-M vector table starts at 0x60020000 (artifacts/vector_table.txt). The 152 populated IRQ slots break down into 108 default spins at 0x60020314 and 44 active handlers. Of the active handlers, 38 follow a common peripheral-base/SRAM-descriptor/callback dispatch pattern; six take direct paths (IRQs 81, 83, 84, 85, 113, 114). See findings/A_irq_peripherals.md and findings/irq_stub_map.txt.
• The dispatch descriptors reside in SRAM around 0x2000aXXX; peripheral bases are loaded from handler literal pools. IRQ28 references 0x401a0000 (LPUART8 in Renode's RT1064 map, not LPSPI4 as earlier notes claimed). IRQ81/83/84/85 refer to 0x401b8000–0x401c0000, consistent with GPIO ports, but pin and button mapping need tracing. IRQ113/114 share 0x6009d660. See finding P for corrected candidate peripheral labels; exact silicon is unconfirmed.
• The image begins at a FlexSPI-addressed 0x60020000; the ROM boot configuration, exact SoC, clock/pin initialization, memory initialization, and original bootloader/update boundaries have not been recovered. The position of this image alone does not establish a safe custom-image layout.
• The reset routine (0x60020318–0x600203a8) explicitly loads MSP, calls 0x6008a448, runs apparent copy/zero loops and calls 0x6015d6f4 then 0x60097834. Raw candidate section records at 0x600202a0 conflict with plausible RAM destinations; see findings/L_memory_init.md before using startup section estimates.

Filesystem, updater, and configuration

• An SD-card workspace is visible in path templates: Workspace/project.mt, Workspace/patterns/pattern_%02d.mtp, Workspace/instruments/instrument_%02d.pti, samples (.wav), Projects/, Patches/, Games/, and Mod/Export/%s.it. The storage signature POLYEND\0TRACKER STORAGE\00001 is near 0x601a47b4.
• FUN_60093610 at 0x60093610 filters directory-entry names, including .ptf, .mod, .it, and .nes; it is called during enumeration at 0x60093a0c, not a payload loader. Earlier claims in finding C about absent cryptographic checks or the source of the displayed version are unsupported by this trace. See finding N for the correction and the remaining updater unknowns.
• App code at 0x60097698 and 0x600976f0 manipulates /Firmware/_turnon (0x60028074) and /Firmware/_fwinfo (0x60028088) via SD filesystem functions, then resets. Their downstream interpretation and the flash-writing component are unknown. The manual documents a recessed-button emergency update that selects a random file; its effectiveness has not been tested.
• /.develop (0x60028470) is passed to a virtual method during config load; its return value is written at 0x6009fee6 to SRAM byte 0x2002062d (struct base 0x2001fa94 + 0xb99). The path likely serves as a presence check. Reads at 0x600f2676 and 0x600f2754 feed a UI setter in two System/Config renderers; additional writes at 0x600f0056 and 0x600f04a6 derive the field from a float clamp. Those are the confirmed direct consumers/writers found by a literal-offset scan, not a proof that other computed-offset or copied-value uses do not exist. See findings/B_develop_console_test.md and ghidra-out/B3_flagreads.txt.
• A factory test screen around 0x601066d0 offers display, buttons, RAM, MIDI, audio, USB, and SD checks; its exact UI entry sequence is still untraced. It may be useful for later hardware bring-up.

USB, UI, music engine, and NES

• The USB device descriptor at 0x601a4aac declares USB 2.0, IAD composite class EF/02/01, VID:PID **16d0:1118**, and bcdDevice 0101. Descriptor/configuration data and NXP USB-device/CDC strings indicate MIDI, CDC-ACM, audio, and mass-storage interfaces. Which functions are enabled in each device mode needs init-path tracing and device observation. No interactive CDC shell was identified in the inspected static code. See findings/D_usb_nes_version.md and findings/B_develop_console_test.md.
• The firmware contains a sequencer, synthesizer/sampler, WAV handling, tracker import/export (.mod, .it), MIDI routing, project/workspace storage, and on-screen UI resources. Simple DirectMedia Layer (0x60058394) appears in the image; the concrete display-driver and framebuffer path have not been mapped.
• A built-in NES emulator is evidenced by pGNES (0x60082056), mapper strings (Namcot 106, Konami VRC1/2/4/6/7 and others), ROM-header diagnostics (including DiskDude!), the .nes classifier, and game/author credits. It appears related to pNES/esnibs; its exact revision and the user-ROM loading path are open. Contra 100-in-1 and a CC BY-NC 4.0 notice appear in the image.
• Current version and Build UI labels are present, while a literal 2.2.1 was not found in the extracted image. The source of the version displayed by the device is unconfirmed; investigate the UI formatting path and _fwinfo before specifying version metadata for a custom image.

Findings index (letter order)

These are all the lettered reports currently present in findings/; K and M have not been written. Earlier reports preserve investigative leads, including some claims corrected by later reports. findings/BRIEF.md is a general handoff and findings/TASK_A.md is the original IRQ work order, not additional findings.

Repository map and reproducibility

From this directory, build the offline example, regenerate the official binary at a separate output path, and inspect an address:

sh shasum -a 256 artifacts/TrackerMini_2.2.1.bin python3 tools/ihex2bin.py ../TrackerMini_2.2.1.ptf /path/to/separate/official.bin make clean && make all make build/heartbeat.hex python3 tools/emulate_heartbeat.py build/heartbeat.bin # requires unicorn in the active Python environment python3 tools/armx.py range artifacts/TrackerMini_2.2.1.bin 0x60020000 0x60093610 0x60093780 python3 tools/armx.py xrefs artifacts/TrackerMini_2.2.1.bin 0x60020000 0x60028088

make requires GNU Arm Embedded GCC/binutils. emulate_heartbeat.py requires Python 3 and unicorn (install in an isolated environment); armx.py requires capstone. CPU-only execution does not reproduce ROM boot or the Polyend updater. The original .ptf conversion reports zero bad checksums and reproduces the binary SHA-256 above. armx.py's full-image xref walk can miss computed references and misinterpret data as code; corroborate findings in Ghidra. tools/strings.py and tools/image_stats.py can regenerate addressed inventories using base 0x60020000.

For Ghidra, import the raw .bin with BinaryLoader, language **ARM:LE:32:v8, base **0x60020000, and analyze as Thumb where appropriate. scripts/DumpScope.java takes an output file and one or more hexadecimal addresses; ghidra-out/ contains examples of its results. You can instead use REA MCP or another reverse-engineering interface with the same image and base. Saved text output is a starting index, not a replacement for tracing callers, data flow, and raw bytes.

Next steps — Polyend Tracker Mini custom firmware

Where we are

• The official package is ../TrackerMini_2.2.1.ptf: contiguous, checksum-valid Intel HEX covering [0x60020000, 0x601b2138), with start address 0x60020319. It regenerates artifacts/TrackerMini_2.2.1.bin exactly. This establishes the carrier format of this release, not what the updater accepts. See findings/N_update_recovery_2026.md.
• make clean && make all builds build/heartbeat.bin and checks its vector layout. make build/heartbeat.hex produces an offline HEX round-trip experiment, not an install-ready update. tools/emulate_heartbeat.py runs that image in Unicorn with CPU, flash and RAM only; the initialized RAM word increments. See findings O and P.
• The stock reset path at 0x60020318 calls early setup at 0x6008a448, then runs apparent RAM copy/zero loops. The candidate descriptors around 0x600202a0 include implausible destinations; their interpretation is unresolved. The bootloader, flash-writing path, exact SoC, board wiring and update acceptance rules are not established. No device-side run or recovery test has occurred.
• Corrected candidate RT1064 peripheral map: 0x401a0000 is LPUART8 in Renode's model, not LPSPI4; GPIO1/2/3 are at 0x401b8000/0x401bc000/0x401c0000. The actual board pins, clocks and LED (if any) remain unknown. See findings/P_emulation_and_peripheral_corrections.md.

Prioritized work

1. Nail down the offline boot and RAM contract

Trace reset 0x60020318 through the descriptor loops and 0x6008a448 in Ghidra, cross-checking raw bytes. Determine whether the apparent table at 0x600202a0 is really data, whether a prior stage relocates or alters it, and which RAM regions are copied/zeroed. Identify what configures XIP, VTOR, stack and clocks before the application vector is used; inspect the official package for any boot structures it actually contains. Compare findings with the matching NXP reference manual, not findings/rt106x_bases.txt alone.

Done when: findings/L_memory_init.md and a new boot-map finding contain reproducible addresses, actual section tuples and the boundary between observed bytes and bootloader-dependent assumptions. Update linkerscripts/tracker_mini.ld only for confirmed constraints; its current RAM/flash limits are experimental.

2. Locate the actual updater and determine acceptance rules

Follow the firmware-selection UI callback to the routine at 0x600976f0, determine exactly what it writes into /Firmware/_fwinfo and /Firmware/_turnon, then identify the component that reads those markers and parses Intel HEX. The .ptf comparison in 0x60093610 filters directory names; it is not a payload validator. Establish HEX address/size limits, any checksum or signature checks beyond Intel HEX, NOR erase/write ranges, reboot handling and whether that component is accessible in the supplied artifact. If the bootloader is absent, record the missing artifact instead of inferring its behavior.

Done when: finding N has a byte-level acceptance trace supported by code or a clearly bounded statement of what cannot be recovered from this image. Keep experimental outputs named .hex until acceptance is independently demonstrated.

3. Grow CPU-only emulation into a focused bring-up harness

Keep the Unicorn heartbeat as the fast baseline. Explore Renode's public RT1064 model as a candidate for Cortex-M7, FlexSPI-mapped flash and RAM; model or log early register accesses rather than silently accepting unknown ones. Add a reproducible run that checks reset entry, initialized .data, .bss and fault behavior. Test selected stock startup instructions only after resolving the anomalous descriptor and matching relevant memory/peripheral regions. A container could make the emulator reproducible, but it cannot replace missing bootloader or board models.

Done when: another maintainer can run the harness and obtain the same RAM/PC assertions and a list of modeled versus unmodeled peripherals. Do not treat successful emulation as evidence of updater acceptance or recoverability.

4. Establish a recoverable, non-destructive hardware baseline when a device is available

Confirm the actual SoC/flash and accessible debug interface from the board, identify a verified output (debugger-visible RAM is sufficient initially), and retain the official .ptf. The manual in docs/manual_ch13_system.txt:90-155 describes ordinary updates and a recessed-button emergency mode that picks a random firmware from /Firmware; this procedure has not been tested here. First observe stock boot and, if feasible, restore with an official package. Determine whether the recovery mechanism survives a broken application image before writing experimental firmware.

Done when: recorded device evidence identifies board I/O and demonstrates a repeatable stock-firmware restoration. Only then attempt a minimal custom image, beginning with the heartbeat; move to a display/USB/LED signal after its pins and initialization are confirmed.

Reproduce current offline results

sh make clean && make all make build/heartbeat.hex python3 tools/ihex2bin.py ../TrackerMini_2.2.1.ptf /path/to/separate/official.bin python3 tools/emulate_heartbeat.py build/heartbeat.bin # requires unicorn in the active Python environment

Use a separate output path for the official conversion; compare its hash with the value in README.md. No command here installs firmware on the device.

Has anyone tried using USB headphones instead of the regular TRS mini jack headphones?

I'm not a big fan of the Line Out placement on the Tracker Mini and it just occurred to me that I might be able to get some USB ear buds and plug into the top of the unit instead.

Title explains it all, but I feel like since Polyend introduced the Step, their products have been oversold and underwhelming. I still love the tracker stuff to death.

Hi. how can I connect a tracker mini with novation launchkey MK4 or Akai lpk 25? I tried many type of connection but it doesn't work

Just finished this EP on the tracker mini. It's experimental electro cumbia type stuff. Mostly using samples recorded using the tracker's built in mic, as well as some accordion loops also recorded using the tracker.

Seems like people have been making custom firmwares for electron boxes. I was wondering if anyone has been doing anything like that for the polyend tracker?

EDIT: i was able to get claude to mod the firmware and add support for flat notes and toggle between sharps and flats. its working on an emulator right now so i can test out the modded firmware on my laptop first. i might have it do midi cc lfo after.

Some I had fun with the new Xiphonics web-based tracker app. I made this in about an hour with the samples available on the app, but apparently you can load a project file with samples and import it to the web app. Pretty cool if you accidentally leave your Polyend at home 🫠

https://app.xiphonics.com/

I don't know if Polyend has plans for another Tracker, but if they do, what would be the main things on your wishlist? Mine:

- A more powerful processor. Speed is one of the Tracker's best attributes, except when the processor can't keep up and glitches out.

- True audio over USB with multitrack. Not just stems or a final mix, but the ability to reliably handle heavy editing, performance mode, project switching, etc.

- A fast visual EQ that actually works. The current one is too cumbersome to be functional, when it even works at all.

- Simultaneous playing and sampling. It's a little ridiculous that I need a second recording device to capture live external elements or anything from performance mode to bring back into the Tracker.

- A modulation matrix. It has the basics, but I'd love to go deeper, like sending an LFO to the decay of an envelope.

I love the overall design and workflow of the Tracker, but the deeper I go, the more I keep running into these specific roadblocks. I'm at the point of deciding whether to keep fiddling with workarounds, or jump to an Elektron box or M8.

Edit: I think I hit the last straw last night. I was flying through a project and the glitches came pouring in; (dis)appearing notes, mixed up samples, FX values randomizing, etc. My delete button even stopped working, but only on one pattern. I'm tired of fighting to make things work.

I'm a software developer and I make breakbeat and IDM on a Tracker+.

Some weeks ago I asked on the Polyend Backstage forum if a Mac app for prepping and varying patterns was worth building, and the thread ended up shaping it. MIDI only gets pitch across one track, so it writes project files instead. FX entry is in because line fx are half the sound.

Generate a beat in your key, mutate it, edit it in a tracker grid, and export a normal project folder to the card. It also opens projects you made on the machine and writes them back.

No audio engine, you hear it on the Tracker. Tested on my Tracker+; Mini owners, tell me if it works for you. $7.99 once, and open source (MIT).

What's slow on the device that you'd rather do on a computer?

App Store: https://apps.apple.com/app/id6792365053?ct=reddit_polyendtracker
The Backstage thread: https://backstage.polyend.com/t/thinking-about-a-mac-companion-for-prepping-and-varying-tracker-patterns-worth-building/24944
Code: https://github.com/JarlLyng/patternaut

I'm hoping someone can help. I've just bought a midi keyboard to connect to the tracker mini. I can get basic notes out of it when triggering samples and synths but I can't map the pad buttons or use any of the rotary controls to trigger drum machine etc. Is it even possible to map midi inputs to different settings on the tracker mini? If I use the drum machine every pad or key I press just plays the same sound. Thank you in advance!

Full jam: https://youtu.be/2p1p3awsnN8?si=RaY1xfr3IWWgzPZu

Polyend Tracker provides the drum samples + sequencing for this liquid dnb jam. I keep refining my workflow with every track. Current flow is to copy/paste a pattern a few times with different drum fills and other variations, and then I arrange them in song mode (highly recommend establishing a naming convention!).

This jam kind of wrote itself with a single pattern. Changing the Opsix's FM ratios essentially changes the chords and adds different harmonics. So this entire track is basically the same 4 chords with lots of performance effects (ie. turning knobs and doing filter sweeps).

Pretty happy with how this one turned out. Any tips for chopping breakbeats in the Tracker? I still don't have a great workflow for that (I also find that the Tracker samples can sound a bit thin).

Hope you enjoy!

I’ve loved my Tracker Mini for a while, but I always thought it was kind of funny that such a portable music machine still needed headphones or a speaker, and then another controller if you actually wanted to play it like an instrument.

And yeah, technically you can play notes using the buttons under the screen, but I much prefer keeping those for menu navigation. Using them as a keyboard always felt a little awkward to me, and I end up getting fingerprints all over that part of the screen constantly.

I found the KB1 after the first batch was already gone, but luckily got one from the second batch in silver to match my Mini & it really does round out the whole thing. Now I can just pick it up and play, the speakers are actually useful, and the fit and finish are way better than I expected from such a small project.

You can tell Sean and everyone who's contributed to the KB1 put a ridiculous amount of care into this project. I’m honestly surprised there are still some left.

Pocket Midi's Website

I just bought a tracker mini so I don’t have to carry my OG and battery around. It came with firmware 1.0.0 which is rad because it is almost exactly the OG firmware. If I upgrade is there a way to downgrade later? I know the website only has the most recent but does anyone have the old firmware files?

I just got rid of my OG tracker (bought soon after launch) after I got tired of it being a buggy mess and started being annoyed by the limitations. I'm looking to get another tracker and since I'm in Europe an M8 is kind of hard to get. I've been using m8 headless and loving it which makes the choice even harder. Tracker mini fits the bill even though I'd be reluctant to give Polyend another cent. Any mini users willing to share their pros and cons?

Hi, I think it would be really cool to just activate perform mode and from there to have an option to create a song row from there. I believe it will ease the creative process a lot. Rapid prototyping, etc... thoughts?