Skip to content

Latest commit

 

History

History
10 lines (6 loc) · 1.79 KB

CodeWhyDoesntItWork.md

File metadata and controls

10 lines (6 loc) · 1.79 KB

Troubleshooting Your Sketch

As developers, we inevitable spend most of our precious time chasing down bugs in our code. Often, this is simply an exercise in tedium and/or deep pondering to figure out how to fix the bug you understand - but other times, figuring out WHY it's not working can be a challenge. This document describes some techniques that can be helpful for finding and/or understanding bugs.

There are two categories of problem - compile-time errors (compile errors). In this case, the 'verify' button will generate an error. If verify works, but 'upload' does not, there is an upload problem, not a compile problem, and the code may be fine. See (TODO: Write up ../UploadErrors)

If it doesn't compile, and you don't understand why, see (./CompileErrors)

If it compiles and uploads fine, but the sketch doesn't do what you want, that is a runtime problem; these can be the hardest problems to solve. (TODO: Start writing RuntimeErrors)

If it compiles, and says it uploaded, but the behavior looks to be unchanged from your previous version - it isn't a weird upload problem, the IDE verifies that what's on the chip is the new code. (It is not even physically possible - there's nowhere other than the flash that a whole sketch worth of data could be stashed within the chip) It is a bug in your sketch, and the change you made actually did not alter the behavior you thought that it would. Either your sketch is exactly the same, or it acts exactly the same (if the size of the sketch is identical with and without that change, that is suspicious; if you "export compiled binary" with the two versions, and the files are the same, then the part of the code you're modifying is unreachable (due to a bug elsewhere), and the compiler realizes that and optimizes it out. See (TODO: Unexpected Optimization).