Closed TrainzLuvr closed 2 years ago
And if I disable it, I get this now:
[31/49] Generating ld/sections.ld
FAILED: esp-idf/esp_system/ld/sections.ld
cmd.exe /C "cd /D R:\CODE\ESP32CommandStation\build\esp-idf\esp_system && C:\espressif\python_env\idf4.4_py3.7_env\Scripts\python.exe C:/espressif/esp-idf/tools/ldgen/ldgen.py --config R:/CODE/ESP32CommanC:/espressif/espC:/espressif/esp-idf/comC:/espressif/esp-idf/components/newlib/system_libs.lfcomC:/espressif/esp-idf/components/app_trace/linker.lf --input C:/espressif/esp-idf/components/esp_system/ld/esp32/sections.ld.in --output R:/CODE/ESP32CommandStation/build/esp-idf/esp_system/ld/sections.ld --kconfig C:/espressif/esp-idf/Kconfig --env-file R:/CODE/ESP32CommandStation/build/config.env --libraries-file R:/CODE/ESP32CommandStation/build/ldgen_libraries --objdump C:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-objdump.exe"
C:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-objdump.exe: uart.c.obj: file format not recognized
Traceback (most recent call last):
File "C:/espressif/esp-idf/tools/ldgen/ldgen.py", line 178, in <module>
main()
File "C:/espressif/esp-idf/tools/ldgen/ldgen.py", line 134, in main
dump = StringIO(subprocess.check_output([objdump, '-h', library]).decode())
File "c:\Miniconda3\lib\subprocess.py", line 411, in check_output
**kwargs).stdout
File "c:\Miniconda3\lib\subprocess.py", line 512, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['C:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-objdump.exe', '-h', 'R:/CODE/ESP32CommandStation/build/esp-idf/driver/libdriver.a']' returned non-zero exit status 1.
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
Master branch seems to have changed significantly since my last pull...
And after deleting the toolchain, build dir and trying again, it compiled without that sections.ld error.
Sigh!
What about FastClock ?
And after deleting the toolchain, build dir and trying again, it compiled without that sections.ld error.
Most likely that error was due to changing from IDF v4.3 to v4.4. I've seen similar and it is always a mess.
What about FastClock ?
I'm not 100% certain what happened there yet. I'll dig into that and see what I can come up with as a quick fix (other than disabling for right now)
Here is something to try:
diff --git a/components/NvsManager/NvsManager.cpp b/components/NvsManager/NvsManager.cpp
index f699231..1dc1965 100644
--- a/components/NvsManager/NvsManager.cpp
+++ b/components/NvsManager/NvsManager.cpp
@@ -465,7 +465,10 @@ namespace esp32cs
{
if (fastclock.operator->() != nullptr)
{
- fastclock->stop();
+ if (fastclock->is_running())
+ {
+ fastclock->stop();
+ }
fastclock->set_rate_quarters(nvsConfig.fastclock_rate);
fastclock->set_year(nvsConfig.fastclock_year + 1900);
fastclock->set_date(nvsConfig.fastclock_month, nvsConfig.fastclock_day);
@@ -535,6 +538,7 @@ namespace esp32cs
fastclock->set_year(nvsConfig.fastclock_year + 1900);
fastclock->set_date(nvsConfig.fastclock_month, nvsConfig.fastclock_day);
fastclock->set_time(nvsConfig.fastclock_hour, nvsConfig.fastclock_minute);
+ fastclock->start();
}
}
diff --git a/main/ESP32CommandStation.cpp b/main/ESP32CommandStation.cpp
index 011a9d3..433d805 100644
--- a/main/ESP32CommandStation.cpp
+++ b/main/ESP32CommandStation.cpp
@@ -383,10 +383,6 @@ void app_main()
init_webserver(&wifi_manager, &nvs, stack.node(),
stack.memory_config_handler(), &train_db);
-#if CONFIG_FASTCLOCK
- fastclock.start();
-#endif // CONFIG_FASTCLOCK
-
// hand-off to the OpenMRN stack executor
stack.loop_executor();
}
It looks like the call to fastclock.start()
should have been moved into the nvs side where the clock is initialized.
I applied those patches but that issue is coming up again, about unknown format for the obj file.
FAILED: esp-idf/esp_system/ld/sections.ld
cmd.exe /C "cd /D R:\CODE\ESP32CommandStation\build\esp-idf\esp_system && C:\espressif\python_env\idf4.4_py3.7_env\Scripts\python.exe C:/espressif/esp-idf/tools/ldgen/ldgen.py --config R:/CODE/ESP32CommandStation/sdkconfig --fragments C:/espressif/esp-idf/components/esp_ringbuf/linker.lf C:/espressif/esp-idf/components/driver/linker.lf C:/espressif/esp-idf/components/esp_pm/linke
C:/espressif/esp-idf/components/spi_flash/linker.lf C:/espressif/esp-idf/components/esp_gdbstub/linker.lf C:/espressif/esp-idf/components/espcoredump/linker.lf C:/espressif/esp-idf
C:/espressif/esp-idf/components/esp_system/linker.lf C:/espressif/esp-idf/components/esp_system/app.lf C:/espressif/esp-idf/components/hal/linker.lf C:/e
C:/espressif/esp-idf/components/esp_wifi/linker.lf C:/espressif/esp-idf/components/lwip/linker.lf C:/espressif/esp-idf/components/log/linker.l
C:/espressif/esp-idf/components/heap/linker.lf C:/espressif/esp-idf/components/soc/linker.lf C:/espressif/esp-idf/components/esp_hw_support/linker.lf C:/espressif/esp-idf/compone
C:/espressif/esp-idf/components/esp_common/common.lf C:/espressif/esp-idf/components/esp_common/soc.lf C:/espressif/esp-idf/components/freertos/linker.lf C:/e
C:/espressif/esp-idf/components/newlib/system_libs.lf C:/espressif/esp-idf/components/app_trace/linker.lf --input C:/espressif/esp-idf/components/esp_system/ld/esp32/sections.ld.in --output R:/CODE/ESP32CommandStation/build/esp-idf/esp_system/ld/sections.ld --kconfig C:/espressif/esp-idf/Kconfig --env-file R:/CODE/ESP32CommandStation/build/config.env --libraries-file R:/CODE/ESP32CommandStation/build/ldgen_libraries --objdump C:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-objdump.exe"
C:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-objdump.exe: rtc_module.c.obj: file format not recognized
C:/espressif/tools/xtensa-esp32-elf/esp-2021r2-patch3-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-objdump.exe: spi_master.c.obj: file format not recognized
That is very weird, it looks like it has some corruption in the build folder?
I deleted the build folder, and retried. Still happening...
The code is sitting on the network share and compiling is done there too. But it hasn't been a problem before, until I upgraded to v4.4.
until I upgraded to v4.4.
Still using Python 3.9 or 3.8 on Windows? Might need to nuke the $HOME/.espressif/ tree and re-run install.sh from IDF to force it to re-create the python venv.
I had to go back to Python 3.7 because 3.8 and 3.9 kept replacing the shared drive letter with a UNC path, and then the error kept coming up that compiling is not supported on UNC paths.
I did reinstall the entire Python venv when upgraded to v.4.4, but I'll try that again. I hope I won't have to do that each time I want to compile...
I hope I won't have to do that each time I want to compile...
If you do then that would be an IDF bug to be logged. It shouldn't be necessary, same for the silly decision on the Python drive letter->network path crap.
Nope, didn't work. Deleted the venv, build folders and still getting this.
I went to look for those 2 files and rtc_module.c.obj was 0 bytes...I deleted both and tried again, still no dice.
I wonder if there's a compilation error elsewhere and thus failing to link these files, but not telling me about it.
That's possible. It could also be some sort of build config setting you are selecting that is resulting in the file being broken. I'm not 100% certain.
I disabled FastClock, deleted the build folder, and still failing to compile.
I'm going to give up now, and maybe go back to ESP-IDF v4.3, since this v4.4 is a dud for me.
I reinstalled ESP-IDF 4.4 using their off-line installer. Then, since it didnt have VFS patch, cloned the 4.4 from github.
After all of this, it failed at the very end with the same issue:
[5/7] Linking CXX executable ESP32CommandStation.elf
FAILED: ESP32CommandStation.elf
cmd.exe /C "cd . && C:\espressif\tools\xtensa-esp32-elf\esp-2021r2-patch3-8.4.0\xtensa-esp32-elf\bin\xtensa-esp32-elf-g++.exe -mlongcalls -Wno-frame-address @CMakeFiles\ESP32CommandStation.elf.rsp -o ESP32CommandStation.elf && cd ."
CMakeFiles/ESP32CommandStation.elf.dir/index.html.gz.S.obj: file not recognized: file format not recognized
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
So, it appears that the issue is with xtensa-esp32-elf/esp-2021r2-patch3-8.4.0.
After going back to xtensa-esp32-elf/esp-2021r2-8.4.0, it compiled on the first try.
That is extremely weird. There must be a bug in the r3 version they published.
Yet it failed to compile ESP32OlcbNodeBrowser, even though I deleted its build folder. This is all weird, and I don't know whether it's their new compiler acting up, because I had no issues with the older version, or my NAS is.
FAILED: esp-idf/esp_system/ld/sections.ld
cmd.exe /C "cd /D R:\CODE\ESP32OlcbNodeBrowser\build\esp-idf\esp_system && C:\espressif\python_env\idf4.4_py3.7_env\Scripts\python.exe C:/espressif/frameworks/esp-idf/tools/ldgen/ld
gen.py -C:/espressif/frameworks/esp-idf/components/bt/linker.lfaC:/espressif/frameworks/esp-idf/components/esp_lcd/linker.lf --input C:/espressif/frameworks/esp-idf/components/esp_s
ystem/ld/esp32/sections.ld.in --output R:/CODE/ESP32OlcbNodeBrowser/build/esp-idf/esp_system/ld/sections.ld --kconfig C:/espressif/frameworks/esp-idf/Kconfig --env-file R:/CODE/ESP3
2OlcbNodeBrowser/build/config.env --libraries-file R:/CODE/ESP32OlcbNodeBrowser/build/ldgen_libraries --objdump C:/espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf
/bin/xtensa-esp32-elf-objdump.exe"
C:/espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-objdump.exe: esp_timer.c.obj: file format not recognized
Traceback (most recent call last):
File "C:/espressif/frameworks/esp-idf/tools/ldgen/ldgen.py", line 178, in <module>
main()
File "C:/espressif/frameworks/esp-idf/tools/ldgen/ldgen.py", line 134, in main
dump = StringIO(subprocess.check_output([objdump, '-h', library]).decode())
File "c:\Miniconda3\lib\subprocess.py", line 411, in check_output
**kwargs).stdout
File "c:\Miniconda3\lib\subprocess.py", line 512, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['C:/espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-objdump.exe', '-h', 'R:/CODE/ESP32OlcbNodeBrowse
r/build/esp-idf/esp_timer/libesp_timer.a']' returned non-zero exit status 1.
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
I'll scrub my zpool overnight and see what happens.
!@#)$^&*% ... Samba 4.13.13 ... POS
I tried gcc all the way back to 5.2.0 and none worked, so it had to be something else. And because the errors were so random, since it was on the network, either the share or the storage.
Since zpool showed no errors, it had to be samba, and I remember it was updated recently.
After installing an older version of Samba, both ESP32CS and ESP32OlcbNodeBrowser compiled on the first try, with the ESP-IDF v4.4 and esp-2021r2-patch3-8.4.0.
Lesson learned.
I tried building from master and got this now, never happened before?
I did enable FastClock in the config.
IDF `release/v4.4