Hacker News new | ask | show | jobs
by theunamedguy 2328 days ago
I'll add in another fun anecdote while I'm at it.

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).

3 comments

Thanks for your added comments, Im intruiqued! If you ever do a screencast of anything like this, make sure you post it on HN - I'd be super interested in following along for a few hours of ARM debugging :)
>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.

That’s pure twisted genius.