First, pull the firmware out of the memory dump and dump the exact loop section in disassembly so you can see the raw op‑codes. In a 32‑bit MCU you’ll usually see something like “CMP R0, #0xFF; BNE loop” – if that compare is off by a sign bit or you’re shifting a signed value, the loop can never terminate. Next, walk through each cycle in a debugger or by stepping through a trace. Watch the program counter, the loop counter register, and the RGB register writes. If you’re writing a palette value, check if you’re incrementing the palette index by one each iteration or by a bit‑shift that eventually overflows into the next channel. A single “INC” on a 32‑bit register that feeds a 24‑bit color buffer will wrap around after 2^32 iterations, and if the display driver reads that buffer continuously you’ll get a rainbow spiral. Also, look at any bit‑field packing. If the RGB value is packed as 0xRRGGBB and you shift left by 8 bits each loop, you’re effectively multiplying by 256 – that will cycle through colors very quickly, and if there’s no delay or a mis‑handled flag, the screen just explodes. Finally, check for any missing write‑back to memory or a volatile qualifier. In some compilers the optimizer will think a register is dead if the value isn’t used, and it can leave the hardware register in a stale state, making the display driver see a changing pattern it shouldn’t. Once you pin down that exact line where the loop counter overflows or the color index wraps, you can insert a proper bounds check or a delay loop, and the rainbow will stop.

Got it, let’s keep the loop under control before it burns the board. First, grab the flash image with a simple read‑out command from your programmer – something like `flash read all > firmware.bin`. Open that binary in a hex editor and locate the loop region. Usually it’s a tight block of three to five instructions. If it looks like `0xE3A00001 0xE2801001 0xE12FFF1E` that’s a classic “move R0, #1; add R1, R1, #1; branch” sequence that will never hit zero. Once you spot the byte pattern, copy those bytes into a small C snippet that you’ll run on the MCU to trigger the watchdog. Example: ```c volatile uint32_t *REG = (uint32_t *)0x20000000; // some SRAM area volatile uint32_t counter = 0; while (1) { counter++; if (counter == 0) { // overflow *REG = 0xDEADBEEF; // force a visible pattern break; } } ``` If you’re using a Cortex‑M, enable the watchdog by writing to the IWDG registers: `IWDG_KR = 0x5555;` and set the reload register to a value that matches the loop period. That way, when the counter wraps, the watchdog resets the MCU and you’ll see a single “reset” flash instead of a full‑blown rainbow. Keep an eye on the timing – if the loop runs every millisecond, set the watchdog to 100 ms. If it’s faster, drop it to 10 ms. Once you’ve got that guard in place, the neon glitch will stay a glitch, not a burn. Happy hunting!