Bad flash command line generation with CMake

Oromis
Posts: 21
Joined: Mon Sep 25, 2017 1:44 pm

Bad flash command line generation with CMake

Postby Oromis » Thu Feb 27, 2020 12:17 pm

Hi,

we just migrated our project from the make-based build system to CMake (on ESP-IDF v3.3.1 on a Windows 10 machine). The project compiles well but when flashing we get the wrong command generated by idf.py:

Code: Select all

>ninja flash
[1/4] Performing build step for 'bootloader'
ninja: no work to do.
[1/2] cmd.exe /C "cd /D C:\coding\esp-idf\components\esptool_py && C:\programs\CMake\bin\cmake.exe -D IDF_PATH="C:/coding/esp-idf" ...h @flash_project_args" -D ESPTOOL_WORKING_DIR="C:/projects/vcu/build" -P C:/coding/esp-idf/components/esptool_py/run_esptool.cmake"
Note: Using default baud rate 460800. To modify, set ESPBAUD environment variable.
esptool.py --chip esp32 -p COM23 -b 460800 write_flash --flash_mode dio --flash_freq 40m --flash_size 16MB 0x1000 bootloader/bootloader.bin 0x8000 partition_table/partition-table.bin esp32/phy_init_data.bin 0xd000 ota_data_initial.bin 0x10000 VCU.bin
The esptool.py command line is invalid since there's no offset specified for esp32/phy_init_data.bin. It makes no difference whether I call "ninja" directly or use "idf.py flash". I tried to trace the offsets through the internals of the build system but wasn't very successful. The file "flash_project_args" looks like this:

Code: Select all

--flash_mode dio --flash_freq 40m --flash_size 16MB 0x1000 bootloader/bootloader.bin
0x8000 partition_table/partition-table.bin
 esp32/phy_init_data.bin
0xd000 ota_data_initial.bin
0x10000 VCU.bin
So here the offset is missing already.

How can I debug this further?

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

Re: Bad flash command line generation with CMake

Postby ESP_Angus » Mon Mar 02, 2020 12:12 pm

Hi Oromis,

Sorry for the delay in getting back to you. I've checked and this is a bug in the v3.3.1 CMake build system, will fix ASAP. In the meantime, you can workaround the bug by removing 4 lines from the file components/esptool_py/project_include.cmake:

Code: Select all

diff --git a/components/esptool_py/project_include.cmake b/components/esptool_py/project_include.cmake
index 6163529b28..b323a13cdf 100644
--- a/components/esptool_py/project_include.cmake
+++ b/components/esptool_py/project_include.cmake
@@ -66,12 +66,6 @@ if(CONFIG_ESPTOOLPY_FLASHSIZE_DETECT)
     set(ESPFLASHSIZE detect)
 endif()
 
-# Set variables if the PHY data partition is in the flash
-if(CONFIG_ESP32_PHY_INIT_DATA_IN_PARTITION)
-    set(PHY_PARTITION_OFFSET   ${CONFIG_PHY_DATA_OFFSET})
-    set(PHY_PARTITION_BIN_FILE "esp32/phy_init_data.bin")
-endif()
-
 get_filename_component(IDF_PROJECT_NAME ${IDF_PROJECT_EXECUTABLE} NAME_WE)
 if(CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES AND NOT BOOTLOADER_BUILD)
     set(unsigned_project_binary "${IDF_PROJECT_NAME}-unsigned.bin")
(This value is also set in the "partition_table" CMake file, and it was accidentally not removed here at the same time - maybe because of a merge problem.)

username
Posts: 538
Joined: Thu May 03, 2018 1:18 pm

Re: Bad flash command line generation with CMake

Postby username » Mon Mar 02, 2020 1:13 pm

Sorry for the delay in getting back to you. I've checked and this is a bug in the v3.3.1 CMake build system, will fix ASAP
I am curious. If we used esp-idf-tools-setup-2.2.exe to install v3.3.1, when there are any fixes are they applied to v3.3.1 or some later version? If applied to v3.3.1, when then is the process to get the update as well?

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

Re: Bad flash command line generation with CMake

Postby ESP_Angus » Tue Mar 03, 2020 2:22 am

username wrote:
Mon Mar 02, 2020 1:13 pm
Sorry for the delay in getting back to you. I've checked and this is a bug in the v3.3.1 CMake build system, will fix ASAP
I am curious. If we used esp-idf-tools-setup-2.2.exe to install v3.3.1, when there are any fixes are they applied to v3.3.1 or some later version? If applied to v3.3.1, when then is the process to get the update as well?
The ESP-IDF Tools Setup will automatically "git clone" one version of IDF, but you can then use Git (or a Git client in an IDE, etc) to fetch updates and "git checkout" a new version in the same local working directory.

The next bugfix release will be v3.3.2 and will probably contain this fix, or v3.3.3 release at the latest (v3.3.2 is currently being finalised so this fix might have missed it.)

There is also a "release branch" named release/v3.3 which allows you to get access to these bug fixes before they are put into a bugfix release.

More general information about the versioning scheme can be found here:
https://docs.espressif.com/projects/esp ... sions.html

Who is online

Users browsing this forum: Google [Bot] and 233 guests