Project Structure for ESP-IDF build with separate FACTORY app

Sysprogs forums Forums VisualGDB Project Structure for ESP-IDF build with separate FACTORY app

This topic contains 3 replies, has 2 voices, and was last updated by  support 1 week, 4 days ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #33199

    AnatoliKrassavine
    Participant

    I have a project based on ESP32-based IOT device using VisualGDB Ultimate with IDF-ESP toolchain and CMAKE. It uses OTA for updates with a dedicated FACTORY partition app. Eg

    • There are two partitions (APP0 and APP1) containing the main app image (quite large and sophisticated)
    • There is a FACTORY partition which contains a small dedicated firmware code. All it does is connecting to secure server and downloading the correct version of firmware for this device.

    All apps must have access to shared NVS configurations, sdkconfig and SPIFFS (not for OTA image itself, but for some data).

    At present, the two codebases are living as separate projects within the same solution. It is inconvenient and creates some issues (eg I need special effort to maintain common settings). I also need to use a custom script to upload final build. I wonder if there is a better way to structure it. For the avoidance of any doubt – things are working. It is not a problem. I just feel that there must be a better way.

    #33200

    support
    Keymaster

    Hi,

    This would be fairly straight forward for the regular CMake projects, since CMake supports multiple applications/libraries in the same project out-of-the-box. However, the use of ESP-IDF makes things more complicated, since it implicitly expects a project to have one primary application referencing multiple components.

    We would advise researching how ESP-IDF internally defines the bootloader targets, since the bootloader is essentially a separate mini-application built within the same project. You might be able to reuse some of that logic to build the application for the FACTORY partition. That said, it might require patching ESP-IDF or might rely on some APIs that will be changed in future versions. It is ultimately something to do at your own risk.

    #33217

    AnatoliKrassavine
    Participant

    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.

    #33220

    support
    Keymaster

    Hi,

    There is no fully automatic way to move a subset of settings between projects, however VisualGDB stores its settings in straight-forward XML files (and ESP-IDF configuration is stored in sdkconfig files), so you could try making a basic automation tool that will move the settings you need between projects.

    You can configure VisualGDB to invoke the custom tool as a custom shortcut (i.e. menu entry under the project context menu).

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.