Thanks for this.<p>Good advice at the end plus a link to an unrelated but equally interesting hardware debug/reverse engineer:<p><pre><code> Lessons for aspiring reverse engineers
Spend a few hours/days reading before you start doing.
Prior knowledge helps. You'll get better at reverse engineering as you do it more.
Code shape is recognizable. SPI drivers all look the same, I2C drivers all look similar, circular buffers all look the same. Code shape is a great hint about code function.
Assume people who wrote the code and designed the chip are sane (until proven otherwise).
Newton's first law of software and hardware design: without a significant outside force, things will keep being designed as they always have been. Assume most designs are similar, and what you saw before is likely what you'll see again
Defaults are not changed most of the time.
Every bit of knowledge helps eliminate possibilities in other places. When something confuses you, leave it alone and go analyze something else. Come back to this one later when you know more.
Weird-looking constants mean things. The weirder the number, the more meaning it probably carries
Have a theory before you rush to try things. An experiment with no theory is meaningless.
Do try things. A theory with no experiment is pointless.
Take notes as you try/figure out things, since your "trying things" binary will quickly become an unmanageable mess and you'll forget things.</code></pre>