Debugging Reset Cause on a Silicon Labs 8-bit MCU

by <a href="http://community.silabs.com/t5/Welcome-and-Announcements/Community-Ranking-System-and-Recognition-Program/m-p/140490#U140490"><font color="#000000"><font size="2">Hero Employee</font></font> </a> MitchC on ‎06-30-2017 02:05 PM

Debugging the cause of an unexpected reset can be tricky, as the debug link can be affected and some systems will not have an easy way to get the reset cause information out of the MCU for analysis.  The following idea may be useful to easily visualize the RSTSRC status whenever you come out of reset, as long as you have 7 GPIO pins to indicate the status of the RSTSRC register bits.  If you do not, then you can use as many as you have and select and/or change the bits you feel most important to view.  I have set up the following code to use GPIO port P2, but you can modify this to use whatever pins you have available.  In this scenario, you would run the following code along with your initialization early in your main() function (i.e. before the main loop) to check the reset source and visualize this by monitoring the pin that corresponds to each reset source in the RSTSRC register:

....................................
   /* Ensure that the crossbar is enabled
    * Set up 7 GPIO to indicate status of RSTSRC bits
    */
   P2MDOUT |= 0x7F;      // set P2.0 - P2.6 to push-pull
   P2 &= ~0x7F;            // clear P2.0 - P2.6

   /* check RSTSRC status and indicate with GPIO pins */
   rst_src=RSTSRC & 0x7F;     // get RSTSRC value
   P2 = rst_src;                // set P2 indicator pins
......................................