Essential Best Practices and Debugging Tips for EFM32 Project Success - Part 1

As a computer engineer of 20 years and a developer of Silicon Labs EFM32 projects for over two years, I am lucky to have a vast background of experience from which to develop complex computer engineering projects.  That’s not required anymore, thanks to tools like Silicon Labs’ Simplicity Studio software and the wide availability of hardware debugger tools such as the EFM32 Starter Kits.  With platforms like these, anyone can get started on embedded development quickly and cheaply.  Within minutes of receiving your Starter Kit, you can be single-stepping through your very own hardware-enabled embedded solution.  My work on this book should give you a good idea of how to get started to make use of all of the bundled peripherals within the EFM32 line of chips.

However, just because you can follow some examples and get lights to blink and electronics to start to function in an example doesn’t always translate into success in your own projects.  My years of experience have guided me to make the correct upfront decisions on how the hardware should be connected, how the software should be architected, and my experience is right there whenever things go wrong, giving me intuition on what to do next in the debugging process to solve the problem.

But what if you don’t have years of experience to lean on?  How can you find success that won’t take years and years to master?  My answer to that question is in the following posts of this series, where I will attempt to distill as many golden nuggets of wisdom that I had to learn the hard way.   You may want to read this guide a few times, and then read it again later when you are stuck on a problem.  It could be the key to solving any number of issues that pop up along the way.

Some of these tips relate to the Simplicity Studio Integrated Developer Environment (IDE) bugs and nuances that may change as Simplicity Studio is improved over time.  But most of the tips in this guide are generic and should apply to all facets of your design from start to finish.

There are six parts to this series:

1. Use a Version Control System

2. Start Development on a Breadboard

3. Plan a Prototype Build

4. Code Well, and Everything Works Better

5. Build Source Code Like a Pro

6. Debug Issues Like a Genius

Before you get started with a new design, take the time to set up a version control system for all of your design work.  This may seem obvious to many, since these systems are so widespread in software development.  But it is very important for embedded development, where a single character difference in a source code file can sometimes be the difference between a working solution and one that completely fails.

Version control systems allow your work to be saved at various snapshots as the design progresses, and allows you to compare differences in your files from each snapshot.  These systems are freely available and can be installed on all types of operating systems (Windows, Mac and Linux).  The most popular tools today are SVN and Git.  I am a user of both systems but I prefer Git these days because it keeps the complete repository including all of the revision history available locally on your computer and you can work completely offline, and then “push” the changes to a remote server later.  SVN, on the other hand, only keeps the most recent revision on your local computer and requires an active connection to the server to fetch past revisions and other history information.

The code examples of this very book are stored in an online Git repository on Github, so it would make sense for you start by “cloning” that repository to your local hard drive and making changes, then experiment with the Git command line or GUI tools to look for the differences in the files.  Setting up and using Git is beyond the scope of this guide, but there are many tutorials out there from which to learn.

Simplicity Studio can be configured to work with Git within the Simplicity Studio IDE.  This allows you to commit changes and look for differences across files right within the IDE.  Details of how to get that setup can be found on the Silicon Labs Community.  Note that the integration is not required to use revision control, and I don’t use the integration on my computer.  I simply run the command line version of Git or the GUI tool on my local folders to make my commits and review differences.

Whenever you start a new project, set up a new version control repository (called a “repo” for shorthand) to store all of the files that pertain to that project.  Go ahead and store all of your specifications and datasheets, design documents, spreadsheets, and so on, in that repo.   You never know when that document you are viewing online may become unavailable or changed by the manufacturer.  It’s good to have a copy in a safe place where it is bundled with the design files.  Don’t stop at documents either.  Store the schematics and layout files for your project in version control as well.

It is best to get an online service such as Github, Atlassian, Google Drive, Microsoft OneDrive, or any other online backup service to keep an extra backup copy of the repo.   When your hard drive crashes or your laptop goes missing, cloning the last server copy of a Git repo is a very quick and easy option to get your design files back on your computer.

Once you have your repo set up and keeping track of your files, make sure to “commit” your design files whenever you reach an important milestone in your project.  When you have just been able to communicate to some chip for the first time, make a commit of the code and specify in the log message exactly the current state of the project even if the source code is a mess of a hack to get it to that point (which it sometimes requires) . For example, “Got accelerometer device ID read out over SPI” is a great message to yourself letting you know that the code that is then committed to the repo basically functions.  What usually happens next is that you clean up the code to make it fancier, more readable and better performing, and sometimes that process breaks the code.  Sometimes the reason for why the code was broken is obvious and you are on your way, but sometimes everything you do to try to fix the issue doesn’t work and you are back at square one with a solution that no longer functions at all.  If you have a committed version of the working code in the repo, all you need to do is first commit your new code to the repo, then rollback your changes on your local drive and see if that original solution still works, which lets you know that at least you aren’t going crazy.  You can then use the difference tools of the revision control system to show differences from the first version to the second version and eventually isolate and fix the issue.

One key difference between embedded development and pure software development is that hardware can change from run-to-run on an embedded application.  When you run the solution the first time, everything works, and then you make some changes and things stop working.  It may seem like the software, but perhaps a wire has wiggled loose somewhere?  By committing your changes to the repo, then rolling back to the last version that worked, you can be sure that the problem is not software, find and fix the loose wire, then update the repo back to the most current version and continue development.

Keys to Success with Version Control

Integrate revision control systems into all facets of your design methodology.

Keep a copy of the repository in an online backup for safekeeping.

Commit early and often, with descriptive messages as to the state of the code.

For additional Silicon Labs product information or technical support, contact Symmetry Electronics, an authorized distributor of industry leading wireless, audio/video and embedded chips, modules and dev/eval tools, call (877) 466-9722.

Source: http://community.silabs.com/t5/Official-Blog-of-Silicon-Labs/Essential-Best-Practices-and-Debugging-Tips-for-EFM32-Project/ba-p/187167