Issue to build the binary from master branch
jholthusen opened this issue · comments
Hi there,
when going through the setup for ESP-IDF and afterwards running your build commands, alls seems to work up to the last command
make -j 8 flash
gives the following error (truncated the output).
jan@DESKTOP-ODC87IQ:~/esp/homepoint/build$ make spiffs_spiffs_bin
Scanning dependencies of target spiffs_spiffs_bin
Built target spiffs_spiffs_bin
jan@DESKTOP-ODC87IQ:~/esp/homepoint/build$
[ 87%] Linking CXX static library liblibsodium.a
[ 87%] Built target __idf_libsodium
[ 87%] Building CXX object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/base64.cpp.obj
[ 87%] Building CXX object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/cbuf.cpp.obj
[ 88%] Building C object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-adc.c.obj
[ 88%] Building C object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-bt.c.obj
[ 88%] Building C object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-cpu.c.obj
[ 88%] Building C object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-gpio.c.obj
[ 88%] Building C object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-dac.c.obj
[ 88%] Building C object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-i2c.c.obj
[ 88%] Building C object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-ledc.c.obj
/home/jan/esp/homepoint/components/arduino-esp32/cores/esp32/esp32-hal-gpio.c: In function '__pinMode':
/home/jan/esp/homepoint/components/arduino-esp32/cores/esp32/esp32-hal-gpio.c:102:24: error: 'rtc_gpio_desc' undeclared (first use in this function); did you mean 'rtc_io_desc'?
uint32_t rtc_reg = rtc_gpio_desc[pin].reg;
^~~~~~~~~~~~~
rtc_io_desc
/home/jan/esp/homepoint/components/arduino-esp32/cores/esp32/esp32-hal-gpio.c:102:24: note: each undeclared identifier is reported only once for each function it appears in
[ 88%] Building C object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-matrix.c.obj
esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/build.make:206: recipe for target 'esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-gpio.c.obj' failed
make[3]: *** [esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-gpio.c.obj] Error 1
make[3]: *** Waiting for unfinished jobs....
[ 88%] Building C object esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/cores/esp32/esp32-hal-misc.c.obj
CMakeFiles/Makefile2:5416: recipe for target 'esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/all' failed
make[2]: *** [esp-idf/arduino-esp32/CMakeFiles/__idf_arduino-esp32.dir/all] Error 2
CMakeFiles/Makefile2:246: recipe for target 'CMakeFiles/flash.dir/rule' failed
make[1]: *** [CMakeFiles/flash.dir/rule] Error 2
Makefile:229: recipe for target 'flash' failed
make: *** [flash] Error 2
could you please advise? I tried to use the source code attached to the release, but it seems to not have the submodules attached, which is sort of logical...
Thanks a lot,
Jan
Hey Jan,
please try cloning and using master if you build from source.
Otherwise. judging from that error you may not be using the ESP IDF 4.0 branch of the Arduino submodule.
I'll update the README/Release Notes to advice people not to build from the Release-Source :)
Hi Matt,
thanks a lot, this helped.
After switching to version 4.0 of ESP-IDF as described in
https://docs.espressif.com/projects/esp-idf/en/latest/versions.html#updating-release-branch
using
cd $IDF_PATH
git fetch
git checkout release/v4.0
git pull
git submodule update --init --recursive
, the build works but doesn't currently provide a set of working binaries. I am working on a setup with Ubuntu on WSL for build and Win10 for uploading the binaries.
When copying the binaries to my Windows file system and calling esptool with the same line as the original script, upload looks fine, but serial monitor shows:
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:6644
load:0x40078000,len:12612
ho 0 tail 12 room 4
load:0x40080400,len:3788
entry 0x40080684
�[0;32mI (60) boot: Chip Revision: 1�[0m
�[0;32mI (69) boot_comm: chip revision: 1, min. bootloader chip revision: 0�[0m
�[0;32mI (41) boot: ESP-IDF v4.0-223-gfdbdf9a0e 2nd stage bootloader�[0m
�[0;32mI (41) boot: compile time 14:45:32�[0m
�[0;32mI (41) boot: Enabling RNG early entropy source...�[0m
�[0;32mI (46) boot: SPI Speed : 80MHz�[0m
�[0;32mI (51) boot: SPI Mode : DIO�[0m
�[0;32mI (55) boot: SPI Flash Size : 4MB�[0m
�[0;32mI (59) boot: Partition Table:�[0m
�[0;32mI (62) boot: ## Label Usage Type ST Offset Length�[0m
�[0;32mI (70) boot: 0 nvs WiFi data 01 02 00009000 00006000�[0m
�[0;32mI (77) boot: 1 phy_init RF data 01 01 0000f000 00001000�[0m
�[0;32mI (84) boot: 2 factory factory app 00 00 00010000 00300000�[0m
�[0;32mI (92) boot: 3 spiffs Unknown data 01 82 00310000 0007d000�[0m
�[0;32mI (99) boot: End of partition table�[0m
�[0;32mI (104) boot_comm: chip revision: 1, min. application chip revision: 0�[0m
�[0;32mI (111) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x1a21c4 (1712580) map�[0m
�[0;32mI (675) esp_image: segment 1: paddr=0x001b21ec vaddr=0x3ffb0000 size=0x038cc ( 14540) load�[0m
�[0;32mI (680) esp_image: segment 2: paddr=0x001b5ac0 vaddr=0x40080000 size=0x00400 ( 1024) load�[0m
�[0;32mI (682) esp_image: segment 3: paddr=0x001b5ec8 vaddr=0x40080400 size=0x0a148 ( 41288) load�[0m
�[0;32mI (706) esp_image: segment 4: paddr=0x001c0018 vaddr=0x400d0018 size=0xda214 (893460) map�[0m
�[0;32mI (996) esp_image: segment 5: paddr=0x0029a234 vaddr=0x4008a548 size=0x0a414 ( 42004) load�[0m
�[0;32mI (1024) boot: Loaded app from partition at offset 0x10000�[0m
�[0;32mI (1024) boot: Disabling RNG early entropy source...�[0m
�[0;32mI (1025) cpu_start: Pro cpu up.�[0m
�[0;32mI (1029) cpu_start: Application information:�[0m
�[0;32mI (1034) cpu_start: Project name: homepoint�[0m
�[0;32mI (1039) cpu_start: App version: 0.01-11-g8d67105�[0m
�[0;32mI (1045) cpu_start: Compile time: Mar 18 2020 14:45:46�[0m
�[0;32mI (1051) cpu_start: ELF file SHA256: 76ef819de9a18ffe...�[0m
�[0;32mI (1057) cpu_start: ESP-IDF: v4.0-223-gfdbdf9a0e�[0m
�[0;32mI (1063) cpu_start: Starting app cpu, entry point is 0x40081298�[0m
�[0;32mI (0) cpu_start: App cpu up.�[0m
�[0;32mI (1073) heap_init: Initializing. RAM available for dynamic allocation:�[0m
�[0;32mI (1080) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM�[0m
�[0;32mI (1087) heap_init: At 3FFBC930 len 000236D0 (141 KiB): DRAM�[0m
�[0;32mI (1093) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM�[0m
�[0;32mI (1099) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM�[0m
�[0;32mI (1106) heap_init: At 4009495C len 0000B6A4 (45 KiB): IRAM�[0m
�[0;32mI (1112) cpu_start: Pro cpu start user code�[0m
⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
... and continues with the weird question marks.
Any pointers how to continue with debugging my build setup?
Apologies, I guess this is n00b stuff.
Thanks a lot,
Jan
Hey Jan,
I'm glueing together 3 different .bin files for the official Github release so Users wouldnt have to flash 3 different binaries (see scripts/build_all.sh).
Can't you access the USB Port through WSL and flash it directly with the build script? (make flash).
Hi Matt,
thanks for the pointer, with the build_all.sh script the build works fine and the resulting .bin boots up on my arduitouch. Maybe it's worth amending the README.md, let me see if I can draft something. Will send you a pull request.
Thanks again!
Jan
Thanks @jholthusen , I guess your case is a special one though.
Regularly, when you build from Master youre not supposed to use the release build script, since most people will have direct access to the COM ports I suppose.
Just curious: Why'd you build from master and not use the Release binary?
Hi Matt,
I already had the binary running, just curious if I can get my Power sensor implemented myself. It's just about including another icon and defining a different sensor type, basically.
I have a set of tasmota-flashed smart plugs which also measure Power consumption, so thought this might be useful.
I get your point about direct access to the COM Ports. Maybe I'll figure it out over the next couple of days.
Ahhh right, youre actually the second one asking to display Power consumption from Tasmota devices.
I merged #46 a while ago which addressed #44.
TL;DR: Finding JSON Keys has been refactored so that you can theoretically use the temperaturehumidity section and replace their JSON Keys with the respective tasmota ones (ie "POWER").
Might wanna replace the icons.
I think I'll do a PR soon and rename temperatuerhumidity to something like genericvalues
Hi Matt,
I did already find that discussion, your approach is a pragmatic one, which should address most issues. Maybe it would be an idea to design the sensors a bit more generic and have a "generic sensor" type which would have a "key", "icon" and "unit" entry in the config.json. That way you could enable people to have their own pix without going into code...
Just a thought...
Jan
Yeah, I'll do a PR for that. Sounds like a good corona-virus-self-isolation-evening project ;)
As for the approach, yeah, it's a hacky one, and it doesnt scale super nicely. But I guess theres only this much flexibility we can offer for the sake of simple usability. If people have a more complex JSON schema they might wanna write their own parsers hehe