Finally gave my MPK mini IV a proper brain transplant - custom firmware, stock bootloader untouched

I spent a while messing with similar chips from the same family and that hash verification process you mentioned was definately the biggest headache. I had one unit where the bootloader check was too aggressive and it wouldn't even accept a single byte change unless the initial flash was absolutely perfect. You have to be really careful with the read/write permissions on the flash memory. It seemed like the original developers walled off that region very tightly. On the unit I worked on, wich was a smaller controller, the ST7735 display didn't run as smoothly as expected when the USB data stream was at its highest rate. I found that increasing the clock frequency slightly on the peripheral SPI bus really smoothed out the animations. It made a noticable difference, expecially when the pattern sequencer was running fast. It is interesting how much the AT32F405 family is used across these smaller gear pieces. I think if someone mapped out the memory maps for the entire line, you could probly build a universal flasher tool much faster. Good job putting this togehter.

I acutally hit a similar wall when porting the basic MIDI handling to a different 32-bit chip, but my issue wasn't the boot process like you mentioned. It was more about the real-time demands of the software. When you're generating those scale-locked chords and running the arpeggiator, the CPU needs to handle the timing perfectly without stuttering. If you spend too many cycles on the UI redraw or the peripheral polling, the sequence gets wobbly.

On the unit I was working with, I found that offloading the timing calculations to a dedicated hardware timer was the only way to keep the tempo solid. It stopped being about the general processing power and became purely about interrupt latency. The display updates, while nice, shouldn't have to dictate the rhythmic engine of the device.

I spent a good two weeks tuning the priority queues for the interrupts, making sure the MIDI input and the clock signal were always at the top of the stack. It felt like overkill, but having a perfectly steady clock even when the screen is drawing complex waveforms made the project feel much more stable. Good work getting the whole system running.

This seems like a big job. I've been looking into using similar chips for a few of my own little builds, but my worry was the flash memory recognition after swapping the firmware. It felt like the driver might choke on the new file layout if it wasn't exactly right. Also, since you added all those features, did you notice if the overall power draw changed at all? I'd hate to see any brownouts when the screen is drawing stuff and the sequencer is running.

I ran into a similar wall a few years back when I was porting firmware onto one of those smaller gear pieces. The AT32F405 chip is solid, but if the power rail isn't clean, you're going to see memory corruption no matter how much you tweak the settings. I used a beefier power supply back then, running everything at a steady voltage instead of relying on the flimsy USB power delivery. When you're wrestling with these SPI displays, the physical trace quality on the board matters just as much as the clock speed, so I always made sure to shield the signal path to keep things sharp.

The way you made it into an 8-track looper on that little thing is seriously clever. I always thought those small controllers were relly limited in what they could actually do, so turning it into a proper recording tool like that is pretty cool. Having the keys automatically lock into the scale you pick sounds like it would make playing way easier and sound better right away. It sounds like you just made a really handy tool for anyone who uses these small keys for music. Since you completley redrew the interface, did you have to change anything about how the pads are mapped compared to the original design, or was it easy to just move them around?