As far as technical problems, there are plenty of optimization sorts of things that come to mind. But I'll go with a different sort. A while back I was working

As far as technical problems, there are plenty of optimization sorts of things that come to mind. But I'll go with a different sort. A while back I was working on an embedded 3D scanner at school. Part of this was using a freescale ARM processor, and a USB interface to transfer scanned models back to the computer. But a weird problem was happening: only when trying to use the USB, every once in a while the processor would have a fault, and the fault was often different and seemingly unrelated. After a week of constantly banging my head on the problem, I came upon a stroke of luck. We were smart enough to have built in a programmer on the board that supported gdb debugging (we built the circuit and populated the PCB). While in a gdb session, I read from the code flash section and noticed that there was a zeroed-out word (4-bytes) that definitely shouldn't have been. More intriguing, a subsequent read was correct, or had a different word zeroed! So the random faults were when one of these zeroed words occurred while code was read (and would have a bad effect depending in the instructions). Now that I had found the problem, the solution wasn't too far, but still took some fiddling. Eventually I found that reducing the flash memory clock fixed the issue. We had all the clocks set to a valid configuration according to the documentation, and they did work fine when the USB module wasn't enabled. But as soon as it was enabled, it apparently interacted with the flash in weird ways. I was glad to find a fix, and luckily we didn't necessarily need the flash to be fast. Embedded systems (and other complex black boxes) can cause some real frustration at times. But it's always fun, and I still found it rewarding :)