Resolving that bug took quite a bit of serendipity. The break came when I was on the verge of giving up on the assembly rewrite and reverting back to C. I'd left my "frozen" iPod sitting around for a while. ~15 minutes later, I came back, and everything was back to normal -- this was evidence that I was not seeing a true lockup, but rather an extremely long delay (consistent with an integer wraparound).
There are virtually no good ways to debug code on-device with Rockbox, short of adding in a bunch of function calls to print variable values to the device's screen. This usual method, though slow, works surprisingly well with most bugs -- but this assumes that the code is in a sane enough state to be able to write to the screen properly (stack corruption, for example, would render it unusable).
There were a few bugs which were not debuggable with this "trace all the things" method, and those were the ones which required the most ingenuity. I remember having to root out a few bugs which absolutely trashed the processor state and made complex things (like function calls to print things) fail miserably.
One such class of bug was the unaligned read (this is ARM, remember). Thankfully, ARM has a way to set an "alignment trap" to trigger an interrupt when an invalid unaligned read happens. The only problem was that, of course, I couldn't figure out what code was responsible for the unaligned read.
My solution to this was quite the gem -- I modified the ARM exception handler to use the iPod's internal piezo buzzer to beep out the faulting PC address in a sequence of 32 high/low pitched beeps. The piezo, driven by a single memory-mapped register, could be controlled with minimal code (and most importantly, no function calls).
This is why I miss working with C in embedded.