Boot loop problem

[shih91]

Hey guys,

I'm back again with another problem. =/

Code: Select all

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3ffc0008,len:0
load:0x3ffc0008,len:1964
load:0x40078000,len:3648
ho 0 tail 12 room 4
load:0x40080000,len:256
entry 0x40080034
I (582) heap_alloc_caps: Initializing heap allocator:
I (583) heap_alloc_caps: Region 19: 3FFC0EDC len 0001F124 tag 0
I (584) heap_alloc_caps: Region 25: 3FFE8000 len 00018000 tag 1
I (594) cpu_start: Pro cpu up.
I (600) cpu_start: Single core mode
I (606) cpu_start: Pro cpu start user code
rtc v134 Oct 20 2016 12:36:18
XTAL 40M
I (876) phy: phy_version: 246, Nov 18 2016, 17:30:07, 0, 0

I (1037) cpu_start: Starting scheduler on PRO CPU.
tcpip_task_hdlxxx : 3ffc498c, prio:18,stack:2048
frc2_timer_task_hdl:3ffc649c, prio:22, stack:2048
~/esp4/esp-idf/components/freertos/./queue.c:1440 (xQueueGenericReceive)- assert failed!
Guru Meditation Error: Core   0 panic'ed (Unhandled debug exception)
Register dump:
PC      :  40083878  PS      :  00060236  A0      :  800836ac  A1      :  3ffc2c10  
A2      :  00000065  A3      :  00000065  A4      :  00000010  A5      :  ffffffff  
A6      :  00000000  A7      :  ffffffeb  A8      :  00000000  A9      :  3ffc2b80  
A10     :  00000000  A11     :  3f40277c  A12     :  3ffc2b4f  A13     :  00000030  
A14     :  00000000  A15     :  3ffc2b55  SAR     :  00000004  EXCCAUSE:  00000001  
EXCVADDR:  00000000  LBEG    :  00000000  LEND    :  00000000  LCOUNT  :  00000000  
CPU halted.

My ESP32 worked in the morning but after I flashed for the first time today, it will go into a reboot loop. I flashed again changing the panic handler option to "print registers and halt" and this is the message i get.

Any idea what this means?

[kolban]

This is where you will want to invest some time in learning the tools needed for handling exceptions. In the register dump shown to you there is a register called "PC" which is the "Program Counter". Think of it as the address in machine code where the exception was detected. By knowing that address, you can then map that to the location in the source code ... and that is what you want to see. You have a couple of choices involving the use of the Xtensa supplied gdb tool. Using this you can load your ELF binary on your PC using gdb and then ask "What is the source line for the given address". That will then tell you exactly what source line you were at when the failure was detected. Alternatively, you can flag the runtime as halting and entering a "GDBStub" when an exception is detected. Now when you run your app and it crashes, not only will you see the same information you see now, you can attach GDB through the serial port to your App and immediately see the location of the problem as well as the "back trace" of how you got there.

There are even more options involving JTAG hardware and software but I personally am ignorant on these and have not yet investigated them.

See the documentation for ESP32 supplied by Espressif, other posts in this newsgroup and free books and articles already written on using debug tools like gdb with ESP32.

From an address by itself, there is nothing at all we can offer to assist further without knowing the source statements and context of the exception. If when you find the location the nature of the issue isn't obvious , don't hesitate to post back with more details.

[ESP_Sprite]

You basically ran into an internal assert, that is, the ESP32 detected some software condition that should never ever be there, but may have occurred because e.g. memory got corrupted. Can you try 'make clean' before re-making it?