[AnatoliKrassavine]

Had a similar problem – here is a solution.

PROBLEM

First of all – it is an ESP-IDF defaults problem – not VisualGDB. Albeit, I would argue that for something like that VisualGDB could have provided a user-friendly configuration override

1. The way partition writing logic is controlled is first esptool_py tool creates partition command skeleton using a fixed template
2. Then, individual components which are interested in adding to partitions (eg spiffs, nvs, etc), add their own entries
3. To support various tools within toolchain, the logic is then used to generate a number of configuration files overlapping in functionality
4. To add rules for writing to partition, one typically uses  either esptool_py_flash_target_image() or esptool_py_flash_to_partition() CMAKE functions. The two functions do the same thing, except that the first one expects you to provide all details (offset, etc), while the second one tries to extract those details from configuration

CONCEPTUAL FIX

So, to fix the problem, we need to do two things:

1. We need to disable the default partition logic which writes the project main binary to the first ‘app’ partition which happened to be mentioned in partition table – which is typically ‘factory’
2. Add explicit partition writing rules to write binaries we want to each project directory

This has the benefit that we keep core ESP-IDF project-neutral and allow each project to define what it likes

STEP-BY-STEP FIX

The default partition logic is located in %ESP_IDF_HOME%\components\esptool_py\CMakeLists.txt

if(CONFIG_APP_BUILD_GENERATE_BINARIES)
partition_table_get_partition_info(app_partition_offset “–partition-boot-default” “offset”)
esptool_py_custom_target(app-flash app “app”)`</div>

# esptool_py_flash_target_image(app-flash app “${app_partition_offset}” “${build_dir}/${PROJECT_BIN}”)
# esptool_py_flash_target_image(flash app “${app_partition_offset}” “${build_dir}/${PROJECT_BIN}”)
endif()

to disable it – comment out the last two lines, as shown</div>

To add your own rules, create a new cmake file – lets call it “custom.flash.config.cmake”
Inside, specify something like that (I am using “esptool_py_flash_to_partition”, as it is cleaner)

esptool_py_flash_to_partition(flash “factory” “${CMAKE_BINARY_DIR}/factory.bin”)
esptool_py_flash_to_partition(flash “app0” “${CMAKE_BINARY_DIR}/MyApp.bin”)
esptool_py_flash_to_partition(flash “app1” “${CMAKE_BINARY_DIR}/MyApp.bin”)

Finally, reference the new CMAKE file from your add the following to your root CMakeLists.txt (assuming that your custom cmake file is in project root directory

include(custom.flash.config.cmake)

That is it.

• This reply was modified 3 months, 1 week ago by AnatoliKrassavine.
• This reply was modified 3 months, 1 week ago by AnatoliKrassavine.

[AnatoliKrassavine]

Thank you for prompt response. Yes, I looked into replicating the way bootloader is built, but it is too proprietary and hard to extend. In my case, the bootloader app is essentially static (it is intentionally not doing anything clever and is kept as simple as possible), so bastardising ESP-IDF built (with all the potential future incompatibilities) for the sake of it does not justify the effort – I totally agree with your accessment.

Saying that, is there a simple way in VisualGDB to automatically replicate certain settings (eg sdkconfig, some properties, board settings, etc) between two projects? Eg I have multiple firmware projects built and tested against the same board setup (which is a custom board which is manufactured for us by third-parties). This board is used for several different products (with different connected sensors and processing logic, but shared comm protocols, etc). With one exception, all products share the same core ESP-IDF configuration, use same libraries, etc.

BTW, factory app is the same for all products – it connects to secure server with device specific credentials and the server returns it OTA image specific to this particular product.

[Author]

Posts