(resolved) reverted IDF version; now program won't run

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

(resolved) reverted IDF version; now program won't run

Postby mzimmers » Wed Mar 13, 2019 6:43 pm

Hi all -

I'd been using the master version of the IDF for several weeks. Because I'm running into a few problems that I just can't explain, I decided to revert to the released version (V3.1.3 I think it is). I needed to change a couple include paths, and make menuconfig ran again, but building was fairly simple.

BUT:

I get this error at the end of the build:
LD build/WifiButton.elf
c:/msys32/opt/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld.exe:esp32.common.ld:39: warning: memory region `rtc_data_seg' not declared
c:/msys32/opt/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld.exe:esp32.common.ld:66: warning: memory region `rtc_data_location' not declared
And, I don't know whether it's related to this, but my program won't run:

Code: Select all

I (0) cpu_start: App cpu up.
I (574) heap_init: Initializing. RAM available for dynamic allocation:
I (581) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (587) heap_init: At 3FFD6468 len 00009B98 (38 KiB): DRAM
I (593) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (599) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (607) heap_init: At 400941C8 len 0000BE38 (47 KiB): IRAM
I (612) cpu_start: Pro cpu start user code
I (315) cpu_start: Starting scheduler on PRO CPU.
abort() was called at PC 0x40083773 on core 1

Backtrace: 0x40089ce8:0x3ffe7960 0x40089ee7:0x3ffe7980 0x40083773:0x3ffe79a0 0x400837a3:0x3ffe79c0 0x4008391d:0x3ffe79f0 0x400fa67b:0x3ffe7a10 0x400f5ed5:0x3ffe7cd0 0x400f5e64:0x3ffe7d20 0x400d6aee:0x3ffe7d50 0x4008124c:0x3ffe7d80 0x400812b9:0x3ffe7da0 0x40007c31:0x3ffe7dc0 0x4000073d:0x3ffe7e30

Rebooting...
I did a "make clean" before rebuilding with V3.1.3. Can someone tell me what I might have forgotten to do? Thanks...
Last edited by mzimmers on Wed Apr 17, 2019 8:46 pm, edited 1 time in total.

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: reverted IDF version; now program won't run

Postby ESP_Angus » Wed Mar 13, 2019 10:46 pm

Hi mzimmers,

Thanks for reporting this. It's a bug when downgrading. Delete the file "build/esp32/esp32.common.ld" and run 'make' again.

(Newer ESP-IDF generates this file in the build/esp32 directory using the linker script generator. Older ESP-IDF V3.1 should just read a static file from the components/esp32/ld directory. However, the linker script search paths are set up so that it finds the build/esp32/esp32.common.ld file even though the 3.1 build system doesn't know anything else about this file.)

Fix coming ASAP.

Angus

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: reverted IDF version; now program won't run

Postby mzimmers » Wed Mar 13, 2019 10:57 pm

Hi Angus - deleting and running make didn't change behavior. I'll try a make clean now and report back.

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: reverted IDF version; now program won't run

Postby ESP_Angus » Thu Mar 14, 2019 2:10 am

mzimmers wrote:
Wed Mar 13, 2019 10:57 pm
Hi Angus - deleting and running make didn't change behavior. I'll try a make clean now and report back.
That's unusual, when I reproduced it I could fix it this way. Try deleting the entire "build" directory.

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: reverted IDF version; now program won't run

Postby mzimmers » Thu Mar 14, 2019 1:50 pm

Still no joy. I've done the following:

- deleted my build directory
- deleted my idf
- downloaded new idf from github
- checkout branch release/v3.1
- git submodule update --recursive
- run make flash

Still getting that abort on startup.

User avatar
fly135
Posts: 606
Joined: Wed Jan 03, 2018 8:33 pm
Location: Orlando, FL

Re: reverted IDF version; now program won't run

Postby fly135 » Thu Mar 14, 2019 3:56 pm

Have you tried a make erase_flash to make sure you are working with a fresh install?

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: reverted IDF version; now program won't run

Postby mzimmers » Thu Mar 14, 2019 4:35 pm

Yes, I did. I also loaded hello_world and that ran fine, so I don't know what to think. I guess I could try building against V3.2 and see if that works. What do you think?

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: reverted IDF version; now program won't run

Postby ESP_Angus » Thu Mar 14, 2019 11:42 pm

Ah, I'm sorry my replies until now were all about the build error not the abort at startup.

Are you able to decode the backtrace from the app? Can be done using idf_monitor, or addr2line (details).

Can you also post the full boot log from your app, please? (Everything from the CPU reset onwards.)

User avatar
mzimmers
Posts: 643
Joined: Wed Mar 07, 2018 11:54 pm
Location: USA

Re: reverted IDF version; now program won't run

Postby mzimmers » Thu Mar 14, 2019 11:53 pm

Here's the boot log:
I (28) boot: ESP-IDF v3.1.3-58-gcea310d5c 2nd stage bootloader
I (29) boot: compile time 06:48:15
I (32) boot: Enabling RNG early entropy source...
I (33) boot: SPI Speed : 40MHz
I (37) boot: SPI Mode : DIO
I (41) boot: SPI Flash Size : 4MB
I (45) boot: Partition Table:
I (49) boot: ## Label Usage Type ST Offset Length
I (56) boot: 0 nvs WiFi data 01 02 00009000 00004000
I (64) boot: 1 otadata OTA data 01 00 0000d000 00002000
I (71) boot: 2 phy_init RF data 01 01 0000f000 00001000
I (79) boot: 3 factory factory app 00 00 00010000 00130000
I (86) boot: 4 ota_0 OTA app 00 10 00140000 00130000
I (94) boot: 5 ota_1 OTA app 00 11 00270000 00130000
I (101) boot: End of partition table
I (105) boot: Defaulting to factory image
I (110) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x3ae94 (241300) map
I (204) esp_image: segment 1: paddr=0x0004aebc vaddr=0x3ffc0000 size=0x03584 ( 13700) load
I (209) esp_image: segment 2: paddr=0x0004e448 vaddr=0x40080000 size=0x00400 ( 1024) load
I (211) esp_image: segment 3: paddr=0x0004e850 vaddr=0x40080400 size=0x017c0 ( 6080) load
I (222) esp_image: segment 4: paddr=0x00050018 vaddr=0x400d0018 size=0xc82bc (819900) map
I (28) boot: ESP-IDF v3.1.3-58-gcea310d5c 2nd stage bootloader
I (29) boot: compile time 06:48:15
I (32) boot: Enabling RNG early entropy source...
I (33) boot: SPI Speed : 40MHz
I (37) boot: SPI Mode : DIO
I (41) boot: SPI Flash Size : 4MB
I (45) boot: Partition Table:
I (49) boot: ## Label Usage Type ST Offset Length
I (56) boot: 0 nvs WiFi data 01 02 00009000 00004000
I (64) boot: 1 otadata OTA data 01 00 0000d000 00002000
I (71) boot: 2 phy_init RF data 01 01 0000f000 00001000
I (79) boot: 3 factory factory app 00 00 00010000 00130000
I (86) boot: 4 ota_0 OTA app 00 10 00140000 00130000
I (94) boot: 5 ota_1 OTA app 00 11 00270000 00130000
I (101) boot: End of partition table
I (105) boot: Defaulting to factory image
I (110) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x3ae94 (241300) map
I (204) esp_image: segment 1: paddr=0x0004aebc vaddr=0x3ffc0000 size=0x03584 ( 13700) load
I (209) esp_image: segment 2: paddr=0x0004e448 vaddr=0x40080000 size=0x00400 ( 1024) load
I (211) esp_image: segment 3: paddr=0x0004e850 vaddr=0x40080400 size=0x017c0 ( 6080) load
I (222) esp_image: segment 4: paddr=0x00050018 vaddr=0x400d0018 size=0xc82bc (819900) map
I (515) esp_image: segment 5: paddr=0x001182dc vaddr=0x40081bc0 size=0x12668 ( 75368) load
I (547) esp_image: segment 6: paddr=0x0012a94c vaddr=0x400c0000 size=0x00064 ( 100) load
I (559) boot: Loaded app from partition at offset 0x10000
I (559) boot: Disabling RNG early entropy source...
I (560) cpu_start: Pro cpu up.
I (563) cpu_start: Starting app cpu, entry point is 0x40081274
I (0) cpu_start: App cpu up.
I (574) heap_init: Initializing. RAM available for dynamic allocation:
I (580) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (587) heap_init: At 3FFD6478 len 00009B88 (38 KiB): DRAM
I (593) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (599) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (607) heap_init: At 40094228 len 0000BDD8 (47 KiB): IRAM
I (612) cpu_start: Pro cpu start user code
I (315) cpu_start: Starting scheduler on PRO CPU.
abort() was called at PC 0x4008377f on core 1

Backtrace: 0x4008d6f4:0x3ffe7960 0x4008d8f3:0x3ffe7980 0x4008377f:0x3ffe79a0 0x400837af:0x3ffe79c0 0x40083929:0x3ffe79f0 0x400fa68f:0x3ffe7a10 0x400f5ee1:0x3ffe7cd0 0x400f5e70:0x3ffe7d20 0x400d6afa:0x3ffe7d50 0x40081258:0x3ffe7d80 0x400812c5:0x3ffe7da0 0x40007c31:0x3ffe7dc0 0x4000073d:0x3ffe7e30

Rebooting...
Here's some of the callback:
$ addr2line -e build/WifiButton.elf 0x4008d6f4
C:/esp-idf/components/esp32/panic.c:676

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x4008d8f3
C:/esp-idf/components/esp32/panic.c:676

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x4008377f
C:/esp-idf/components/newlib/locks.c:81

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x400837af
C:/esp-idf/components/newlib/locks.c:134

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x40083929
C:/esp-idf/components/newlib/locks.c:171

MZimmers@mzimmers-w10p MINGW32 /c/esp32_projects/wifibutton
$ addr2line -e build/WifiButton.elf 0x400fa68f
/Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf.c:860 (discriminator 2)
Thanks for any help...

ESP_Angus
Posts: 2344
Joined: Sun May 08, 2016 4:11 am

Re: reverted IDF version; now program won't run

Postby ESP_Angus » Fri Mar 15, 2019 12:07 am

It looks like allocating the lock for a printf() call failed for some reason.

Can you please give us the full call stack, so we can see exactly what started this sequence of events? If you can, please pass the "-pfia" options to addr2line as well (among other things, this will include the function names in the output which saves some time.)

(Tip: To save more time if doing this by hand, you can run addr2line once without any address as an argument, and then paste each backtrace address in on a new line.)

Who is online

Users browsing this forum: No registered users and 142 guests