Esp-idf: WindowOverflow4 at ??:?

[forthlightning]

I see this line:

0x40080000: _WindowOverflow4 at ??:?

repeated twice toward the beginning of the device boot.

What does this mean? Is this going to break something later?

This occurs even when I use the default partition table.

Flashing binaries to serial port /dev/tty.SLAB_USBtoUART (app at offset 0x10000)...
esptool.py v2.0-beta2
Connecting........_____....._____....._____.....__
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Attaching SPI flash...
Configuring flash size...
Auto-detected Flash size: 4MB
Wrote 16384 bytes at 0x0000e000 in 0.2 seconds (657.2 kbit/s)...
Hash of data verified.
Flash params set to 0x0220
Wrote 16384 bytes at 0x00001000 in 0.2 seconds (650.8 kbit/s)...
Hash of data verified.
Wrote 802816 bytes at 0x00010000 in 10.9 seconds (590.7 kbit/s)...
Hash of data verified.
Wrote 16384 bytes at 0x00008000 in 0.2 seconds (661.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting...
MONITOR
--- idf_monitor on /dev/tty.SLAB_USBtoUART 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

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

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (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:0x3fff0008,len:8
load:0x3fff0010,len:2488
load:0x40078000,len:7128
load:0x40080000,len:252
>>>0x40080000: _WindowOverflow4 at ??:?
entry 0x40080034
>>>0x40080034: _WindowOverflow4 at ??:?
I (1214) cpu_start: Pro cpu up.
I (1215) cpu_start: Single core mode
I (1216) heap_alloc_caps: Initializing. RAM available for dynamic allocation:
I (1229) heap_alloc_caps: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (1249) heap_alloc_caps: At 3FFC90B8 len 00016F48 (91 KiB): DRAM
I (1270) heap_alloc_caps: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (1291) heap_alloc_caps: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1313) heap_alloc_caps: At 4009B824 len 000047DC (17 KiB): IRAM

[projectgus]

What does this mean? Is this going to break something later?

Short answer: It's not a problem, it's an unintended consequence of the new idf_monitor tool.

Long answer:

Anything which is printed that looks like a code address is looked up to a symbol/function/code name in the ELF file.

In this case:

load:0x40080000,len:252
>>>0x40080000: _WindowOverflow4 at ??:?
entry 0x40080034
>>>0x40080034: _WindowOverflow4 at ??:?

Are the section load & entry pointer addresses, printed by the bootloader. idf_monitor sees the addresses looks them up (via addr2line) for symbol/function names and finds the "function" _WindowOverflow4 (an Xtensa exception vector) and ??:? for the source file and line. None of which is very useful!

Probably we can find a way print something less ominous sounding here (possibly by injecting a symbol at the beginning of the ELF file.)

[forthlightning]

Ok, thanks for the quick reply!

I thought it was something wrong with my partition scheme.

BTW loving the inline stack trace decoding.