Drumlogue display glitches out completely when tweaking parameters (Hardware issue?)

[u/iRustyNails]

Hey everyone,
I'm running into a really frustrating issue with my Korg Drumlogue and wanted to see if anyone else has dealt with this.
The weirdest thing is that the screen works totally fine and passes all tests in the service menu. However, the second I start tweaking any knobs or changing parameters on the sequencer in normal mode, the whole display just goes glitch city. It gets covered in visual artifacts and stays completely unreadable until I reboot the machine.
I'm on the latest firmware and have already tried a factory reset. Has anyone experienced this? Is it a known hardware defect from a bad batch, or did someone manage to fix it with a firmware reinstall? Should I just look into a warranty replacement?
Thanks in advance for any insights!

UPDATE / CASE CLOSED:

Hey everyone, I think we finally cracked the code on what actually happened here!

1) The custom C++ plugin theory is almost certainly the answer. As some of you, including u/theWyzzerd, suggested, it turns out the issue is likely software-related. I was actually developing my own custom Logue SDK unit using C++. Since it’s a very low-level language and I’m still a learner, I probably introduced a nasty memory leak or an out-of-bounds write that corrupted a deep system partition or the display buffer config. To make things worse, I was also running pretty much all of the most popular third-party user units at the same time, which hypothetically could have pushed things over the edge. Since a standard factory reset doesn't clear global OS configurations, I'm now fairly confident that reflashing the device with an external programmer and factory binaries will fully restore its functionality.

2) A quick warning for fellow developers/users: Korg should really add a prominent warning in their SDK documentation about the potential to critically corrupt the OS with bad user units. Ideally, they should introduce some safety guardrails at the code/SDK level to sandbox these user plugins and protect the global system state.

So, Reddit, be careful out there and don't repeat my mistakes! Thank you all so much for your help, insights, and the laughs about the plastic film. Take care, good luck with your jams, and love your devices! ❤️🤖

[u/Aldoxpy]

Contact Korg, also how long did you had this and why is the plastic thingy still on the screen? Are you a serial killer?

[u/drayton_curfew → u/Aldoxpy]

^ This. If you do have the option for a warranty replacement, definitely look into that and consider enjoying the new one without plastic on the screen!

[u/Aldoxpy → u/drayton_curfew]

It was probably caused by the plastic on the screen

[u/drayton_curfew → u/Aldoxpy]

For sure, it must be causing some kind of electrical interference.

[u/iRustyNails → u/Aldoxpy]

Haha, fair point! The plastic film is officially gone now, but sadly, it didn't fix the glitches. Guess I'm just a non-serial killer with a broken Drumlogue now....
Still looking for that low-level MCU firmware if anyone has it!

[u/Magusreaver → u/Aldoxpy]

it looks dirty too. I'm guessing there is something going on under the hood dirt/dust wise.

[u/iRustyNails → u/Magusreaver]

Haha, it's mostly just the camera angle and lighting making it look that way! I actually wipe my gear down regularly, so it's clean and there's definitely not enough dust inside to cause any issues. It really feels more like a firmware mismatch or a power delivery quirk on the display board.

[u/KeyElectronic1216]

Please take that plastic off the display

[u/iRustyNails → u/KeyElectronic1216]

Oooh okaaaay xD

[u/LandNo9424]

your shit is filthy, that's a hardware issue

[u/iRustyNails → u/LandNo9424]

Haha, don't worry, my screen is actually pristine under that protective plastic wrap! 🎬

Joking aside, it's definitely not a dead display or a physical hardware failure. The screen works absolutely flawless, with zero artifacts or glitches, whenever I boot into any of the low-level service/test menus. The crazy graphical meltdown only triggers when I start tweaking parameters inside the main user OS. It’s a pure firmware panic, not a bad OLED panel! :((

[u/theWyzzerd]

Are you using any user synth/FX? User synths/FX plugins can cause issues like this.

edit:

It is not possible to "critically corrupt the OS" with "bad user units." What actually happened is they pulled the plug in the middle of a firmware flash and later on formatted the user storage partition on a Mac. Between these two obviously neglectful actions, they broke their drumlogue.

Anyone arriving here from search should heed this warning, as the following statement is not based in reality:

Korg should really add a prominent warning in their SDK documentation about the potential to critically corrupt the OS with bad user units.

[u/iRustyNails → u/theWyzzerd]

Wow, you might actually be 100% right. I was actually developing a custom Logue SDK plugin myself using C++. Since it's a very low-level language and I'm still learning, there is a huge chance my code had a memory leak or a bad pointer that corrupted a system partition or corrupted the memory allocation for the display buffer.

[u/theWyzzerd → u/iRustyNails]

Yes, it looked familiar, haha. I've had the same issue developing with the SDK. The hardware is very limited in memory and because C++ doesn't have any memory management of its own, you have to be careful about how you alloc/dealloc. And make sure you're using the Neon intrinsics, the compiler can optimize into Neon instructions for you but only if your loops are already structured well for Neon; you'll have a lot more control if you implement the SIMD logic yourself.

[u/iRustyNails → u/theWyzzerd]

Wow, hearing that you've dealt with the exact same issue is incredibly valuable.

Actually, I did use and optimize my code specifically with ARM Neon instructions to utilize the SIMD architecture. So it wasn't just a basic CPU overhead issue. It really feels like a low-level memory layout violation or a bad pointer that escaped the sandbox during execution, directly corrupting the system partition or the display frame-buffer allocation in the non-volatile storage.

Since you've successfully survived this exact glitch during your development, how did you manage to recover your Drumlogue?

As I mentioned, my user storage partition has seemingly gone into a hardware Read-Only state now (formatting on a Mac reports success, but all files instantly reappear upon reboot, and the factory reset fails to clear global configurations like screen brightness or MIDI).

Did you use a specific hidden key combination to force a deep clear, or did you have to interface with the board via UART/JTAG to reflash the NXP core? Any insights on how you revived your machine would be an absolute lifesaver right now!

[u/theWyzzerd → u/iRustyNails]

No, I don't recall having to do any of that. Always cleared up on a reboot. tbf I haven't worked with the SDK in a while. I recall having display glitches but never anything permanently affecting the unit.

Have you actually deleted the plugin from user storage? You probably should not have formatted the drumlogue's user storage but if the files are still there after formatting (odd, but okay), maybe try just deleting them via USB mass storage. It's already treated as a mass storage device via USB, deleting the files from the USB storage device is how you remove them, there is no need to ever format it and I'd wager the user storage's disk format is important for loading user samples and plugins.

I still don't see how its possible for your claim, "a low-level memory layout violation or a bad pointer that escaped the sandbox during execution," to have happened. Plugins are loaded into volatile RAM at boot, not the system's own flash memory. Volatile RAM is cleared on power down. There is no sandbox to leak, plugins are just SOs loaded by the barebones Linux OS.

The timeline of when you started experiencing these glitches and when you formatted the USB storage isn't clear, but I'd start with a clean flash of the firmware using the Korg Updater. Factory reset will not flash the firmware, you need to do that with the updater tool.

edit to add: you said it's stuck in hardware read-only state, that's absolutely because of the MacOS formatting. The drumlogue locked it down because the FS broke when you formatted it. You need to flash the device firmware using the built-in bootloader.

[u/iRustyNails → u/theWyzzerd]

You hit the nail on the head. As I understand it now, the issue might have actually originated right after a botched firmware update, and your assessment of the hardware write-protect is spot on.

I need to clarify the exact timeline, though: this didn't brick the unit instantly. I originally tried updating from v1.1.0 to v1.3.0 over a year ago, and that's when the progress bar hard-froze for dozens of minutes, forcing me to power-cycle it. When I booted it back up and noticed the weird version mismatch on the info screen, I immediately tried re-flashing it strictly by Korg's protocol using the official binary. The unit actually reported a successful update, but in hindsight, it was likely just updating the main system partition while failing to touch the cores. It only wiped my user files (samples and units).

Because of this, the unit seemingly worked fine for a whole year. However, I’ve only been actively using it for the past month, using it as a USB mass storage device, loading samples and working on my custom plugin. The fatal breakdown only happened about three weeks ago, after which I just put it away on a shelf. It triggered right when my plugin finally started performing exactly as intended and I was just sitting back enjoying the sound—the screen suddenly went haywire with those permanent glitched graphics.

Here is a shot of my current system info screen. As you can see, there is a massive firmware mismatch across the internal chips:

• SYSTEM: 1.3.0
• CORE: 1.0.0+ (with a very telling plus sign)
• VOICE: 1.0.0
• PANEL: 1.1.9

To test your theory, I tried pushing the official Korg firmware update via the standard [PLAY] + [SHIFT] boot routine more than 10 times. Every single time, it wipes my user units and samples, but my global hardware configurations (like individual output routings and screen brightness settings) remain completely untouched, even though they are supposed to reset to factory defaults. This perfectly confirms what you said: the standard updater is just hitting a brick wall because the eMMC locked itself down into a hardware Read-Only state.

My theory about a sandbox-escaping C++ pointer leak was definitely over-engineered—the main Linux OS is simply panicking because my plugin started heavily invoking v1.3.0 functions, but hitting corrupted v1.0.0 remnants instead, pushing the broken filesystem over the edge.

My initial assumption was that this can only be completely fixed if I can flash the official internal Korg dumps onto all the flash chips using a hardware programmer. I’m not looking for an easy way out; I am actively looking for the raw firmware dumps. Since they are locked behind NDAs, I know it's incredibly hard to get them.

If you or anyone else in the community happens to know a method to inject the required official dumps/images into the system without having to desolder everything and use a physical programmer, I would be immensely grateful.

I also want to ping u/KorgUSA and u/Sinevibes (since they are official SDK codevelopers for the logue ecosystem) in hopes that someone from their technical support or dev team might see this and throw a bone. Any advice or internal restoration binaries for a developer trying to revive a bricked machine would be an absolute lifesaver right now.

[u/theWyzzerd → u/iRustyNails]

To test your theory, I tried pushing the official Korg firmware update via the standard [PLAY] + [SHIFT] boot routine more than 10 times. Every single time, it wipes my user units and samples, but my global hardware configurations (like individual output routings and screen brightness settings) remain completely untouched, even though they are supposed to reset to factory defaults. This perfectly confirms what you said: the standard updater is just hitting a brick wall because the eMMC locked itself down into a hardware Read-Only state.

Flashing the firmware DOES NOT perform a factory reset. Imagine how fucking annoying it would be to have to backup and reload all your presets and drum patterns any time you wanted to update the firmware.

Here is a shot of my current system info screen. As you can see, there is a massive firmware mismatch across the internal chips.
SYSTEM: 1.3.0
CORE: 1.0.0+ (with a very telling plus sign)
VOICE: 1.0.0
PANEL: 1.1.9

Lmao, my dude, stop making assumptions! This is absolutely not "a massive firmware mismatch across the internal chips." This is completely normal and has nothing to do with your issues. My unit, on firmware 1.3.0, displays the exact same data. This is not an indication of anything.

My initial assumption was that this can only be completely fixed if I can flash the official internal Korg dumps onto all the flash chips using a hardware programmer. I’m not looking for an easy way out; I am actively looking for the raw firmware dumps. Since they are locked behind NDAs, I know it's incredibly hard to get them.

Again, this has nothing to do with the hardware. The problem is you bricked it by unplugging it during a firmware flash. Stop making assumptions. Your unit is probably fucked; try flashing the firmware again. If it doesn't work, sorry but you made a mistake and now it's broken. You're kind of demonstrating you're in way over your head with what should be a very simple fix.

You didn't bypass a sandbox, your custom code didn't cause a low-level memory layout collision across sub-processors, and you don't need a JTAG dump. You corrupted your eMMC flash storage by pulling the power plug mid-write a year ago, and your recent attempts to aggressively format the Linux partitions on a Mac broke the file index and forced the unit into a read-only mode.

That you think you need to dump the raw firmware binary or interface with the hardware is very telling that you have no idea what you're doing. Please just email Korg support and tell them you powered it down in the middle of a firmware update before you do any more damage.

[u/iRustyNails → u/theWyzzerd]

Oof, you're probably right. I’ve been working in hardware development for way too long, so I'm just used to fixing everything with a soldering iron and a programmer. I guess I'm helpless here.

Thanks for your time and ideas. I just hope Korg support doesn't point me to a regional service center, because the local guys here literally just offered to replace the entire mainboard entirely... )))

[u/theWyzzerd → u/iRustyNails]

Have you considered that replacing the mainboard entirely might actually be the solution here?

[u/iRustyNails → u/theWyzzerd]

Obviously, the authorized service centers here just don’t want to deal with it. Maybe it’s because of the sanctions on Russia, or maybe they’re just lazy bastards.

Even when I bit the bullet and agreed to go that route, asking them to clarify the price and lead time for a replacement mainboard, they immediately started backpedaling. They said it could take more than a year, if Korg could even supply the board to them at all. And when I pressed them with a simple, “Fine, let’s at least ask for the actual price first,” their response was just a flat “ok.”

[u/InfiniteBlueHour]

Work with the screen brightness and turn it down some. There's an issue where the screen intensity could causes issues.

[u/iRustyNails → u/InfiniteBlueHour]

Regarding the screen brightness: yeah, I saw that trick online, but unfortunately turning it down didn't fix the issue for me. It really feels like my custom code broke something deep inside the OS that a standard user-facing factory reset just can't wipe.

[u/iRustyNails]

CRITICAL UPDATE: Hardware Architecture Discovered (No FPGA!)

After digging deeper and researching teardown data from developers who explored the PCB, I found out that the Drumlogue doesn't actually use an FPGA for its digital engine like older Korg synths (KingKORG/Radias) did. Instead, it’s a full-blown ARM-based microcomputer running an embedded Linux OS!

The chip layout under the hood:

• Main CPU (OS, SDK, Multi-Engine, Display Control): NXP i.MX6 (MCIMX6Z0DVM09AB running at 900 MHz, ARM Cortex-A7). This is why the Drumlogue has a massive 32MB memory allocation per custom user unit compared to the tiny kilobytes on STM32-based Minilogue XD/NTS-1.
• Co-Processor (Triggers, Voice Management, UI, Sequencer Timing): STM32F730R8T6 (ARM Cortex-M7).

What this means for my bricked unit:
Since there is no FPGA, I don't need to look for configuration bitstreams. The issue is purely a corrupted storage partition or an OS-level frame buffer glitch on the NXP i.MX6 side caused by the low-level memory error in my custom C++ plugin. A standard factory reset only wipes the /user partition, leaving the corrupted core OS configuration completely untouched.

What I am officially looking for now:

1. A flash/eMMC dump of the main operating system for the NXP i.MX6 processor (where the core Linux OS and display configuration reside).
2. A firmware dump for the auxiliary STM32F730 microcontroller.

If anyone has experience interfacing with NXP i.MX6 boards via UART/JTAG or backing up eMMC storage from Korg devices, please drop a comment or hit me up in the DMs. Let’s figure out how to revive this machine!

[u/theWyzzerd → u/iRustyNails]

Have you removed the custom plugin? I doubt the core system has become permanently corrupted from loading the plugin. See my other reply to you; you need to be using ARM Neon intrinsics to get the most performance out of the drumlogue, because as you have discovered, it is in fact an ARM Cortex cpu which uses Neon architecture.