! Version 1.0 Copyright © 2016 ESP8266 Reset Causes and Common Fatal Exception Causes About This Guide This guide introduces the methods of identifying the causes of ESP8266 reset and common Fatal exceptions. The guide structure is as follows: Release Notes Chapter Title Content Chapter 1 Reset Causes Introduction to two methods of identifying ESP8266 reset causes: ROM code and user program. Chapter 2 Common Fatal Exceptions and Causes Description of common ESP8266 Fatal exceptions and their causes. Date Version Release notes 2016.08 V1.0 Initial Release. Table of Contents 1. Reset Causes! 1".......................................................................................................................... 1.1. Identifying Reset Cause in ROM Code! 1"...................................................................................... 1.2. Identifying Reset Cause Using User Program! 1"............................................................................ 2. Common Fatal Exceptions and Causes! 3................................................................................. ! 1. Reset Causes 1. Reset Causes 1.1. Identifying Reset Cause in ROM Code Each time ESP8266 reboots, the ROM code will print out a number corresponding to the reset cause, as the following figure shows. You can verify the cause of the reset based on the number. Use this as a debugging method when you cannot start the user program and need to analyze the cause of the reset. ! The following table shows reset causes printed in ROM code. 1.2. Identifying Reset Cause Using User Program You can also identify the reset cause by adding an application layer program, which provides relatively comprehensive analysis of the reset cause. Use this method when garbled output is printed where crash occurs and can not be debugged. Add the following code segment: structrst_info*rtc_info=system_get_rst_info(); Table 1-1. Identifying Reset Cause in ROM Code Rst cause No. Cause 0 Undefined 1 Power reboot 2 External reset or wake-up from Deep-sleep 4 Hardware WDT reset ⚠ Notice: The reboot state will not change after software WDT reset or software reset. For example, when the first reset is caused by a power reboot, the rst cause number is 1. After software reset, the rst cause number will still be 1. Espressif ! /!1 4 2016.08 ! 1. Reset Causes os_printf("resetreason:%x\n",rtc_info->reason); if(rtc_info->reason==REASON_WDT_RST|| rtc_info->reason==REASON_EXCEPTION_RST|| rtc_info->reason==REASON_SOFT_WDT_RST){ if(rtc_info->reason==REASON_EXCEPTION_RST){ os_printf("Fatalexception(%d):\n",rtc_info->exccause); } os_printf("epc1=0x%08x,epc2=0x%08x,epc3=0x%08x,excvaddr=0x%08x, depc=0x%08x\n", rtc_info->epc1,rtc_info->epc2,rtc_info->epc3,rtc_info- >excvaddr,rtc_info->depc);//Theaddressofthelastcrashisprinted,whichisusedto debuggarbledoutput. } For information on system_get_rst_info() and associated data structures, please refer to ESP8266 Non-OS SDK API Reference and ESP8266 RTOS SDK API Reference (link: espressif.com/en/support/download/documents). The following table shows the reset causes identified by adding user program. Table 1-2. Identifying Reset Cause Using User Program Rst cause No. Cause GPIO state 0 Power reboot Changed 1 Hardware WDT reset Changed 2 Fatal exception Unchanged 3 Software watchdog reset Unchanged 4 Software reset Unchanged 5 Deep-sleep Changed 6 Hardware reset Changed Espressif ! /!2 4 2016.08 ! 2. Common Fatal Exceptions and Causes 2. Common Fatal Exceptions and Causes When a program crashes, you can debug the crash based on the Fatal exception number. The following table shows common Fatal exceptions and their possible causes. For example: Fatalexception(28):! epc1=0x4025bfa6,epc2=0x00000000,epc3=0x00000000,excvaddr=0x0000000f, depc=0x00000000 • If user1.1024.new.2.bin is used, verify the exception address “0x4025bfa6” in the user1.1024.new.2.S file. Add print to the user’s code to debug the Fatal exception. • If eagle.irom0text.bin is used, verify the cause of the Fatal exception in the eagle.S file. • If the address of exception cannot be found, it means that the crash occurs during an interrupt, or that there is a code problem in ROM, such as: - 4000e190 - 4000df48 - 4000dea8 - 4000de84 - 4000e1e0 Table 2-1. Common Fatal Exceptions and Causes Fatal exception No. Description Possible Causes 0 Invalid command 1. Damaged BIN binaries 2. Wild pointers 6 Division by zero Division by zero 9 Unaligned read/write operation addresses 1. Unaligned read/write Cache addresses 2. Wild pointers 28/29 Access to invalid address 1. Access to Cache after it is turned off 2. Wild pointers Espressif ! /!3 4 2016.08 Disclaimer and Copyright Notice Information in this document, including URL references, is subject to change without notice. THIS DOCUMENT IS PROVIDED AS IS WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. All liability, including liability for infringement of any proprietary rights, relating to use of information in this document is disclaimed. No licenses express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein. The Wi-Fi Alliance Member logo is a trademark of the Wi-Fi Alliance. The Bluetooth logo is a registered trademark of Bluetooth SIG. All trade names, trademarks and registered trademarks mentioned in this document are property of their respective owners, and are hereby acknowledged. Copyright © 2016 Espressif Inc. All rights reserved. Espressif IOT Team" www.espressif.com
