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.