• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 119 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2634-Q1: FreeRTOS project structure for dual cluster with lock step.

Vijay Kumar Arwapally
Prodigy 10 points

Part Number: AM2634-Q1
Other Parts Discussed in Thread: SYSCONFIG

Looking into the examples for FreeRTOS usage with AM2634-Q1, which has 4 cores.
My project requirement is configure the controller in lock-step mode with two clusters.

For this, why is the project structure so complicated? need to build two projects, duplicate syscfg files, generated files are duplicate.

multiple linker files. Too many dynamic files being linked during build process from SDK and FreeRTOS build.

Very difficult to get build structure with CMake kind of approach.

Any better way to manage project structure without duplication? 

  • 0
    TI__Mastermind 23562 points

    Hi Vijay,

    Apologies for a delayed response i was on travel and could not get back earlier. Let me help with the confusions here.

    1. The SBL is used to configure the device into lockstep mode. The sysconfig file for SBL will contain parameters for this as shown below

    SBL will handle all lockstep configuration, before booting your application.

    2. You do not need to maintain duplicate copy of projects for core_0-0 and core0-1 OR core1-0 and core1-1. You only need to maintain/build core-0-0 and core1-0 projects (1 for each cluster).

    The SDK uses separate syscfg file and separate linker files for each cluster as different cores will have their own memory maps and own reset vectors.

    Apart from this, the libraries are static pre-built ones only linked during the final application build. Since the SDK does not rely on CMAKE infrastructure inherently, there might be folder/sub-folder level changes needed. the SDK uses default makefile infra and wont work out-of-box for CMAKE infra. This will need additional re-structuring and movement of SDK files in your build pipeline.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 10 points

    Thx for the response!

    So basically that would mean, three projects in total:

    • SBL
    • Cluster 0
    • Cluster 1

    And another umbrella project to manage combined clusters app.

    All the above projects would have there individual syscfg files.

    1. Should there be any common cfg in all the syscfg files?(clk, mem etc?)
    2. Can the same peripherals be configured in both clusters?

    Any guide to migrate to CMake style build?

  • 0 in reply to Vijay Kumar Arwapally
    TI__Mastermind 23562 points

    Yes, typically the setup will involve the following projects:

    1. SBL (Secondary Boot-loader)

    • Responsible for configuring the device boot flow and enabling lockstep mode for the R5F clusters.
    • Performs system initialisation before loading the application images.

    2. Cluster 0 Application - Built for R5FSS0-0 (cluster 0 primary core).
    3. Cluster 1 Application - Built for R5FSS1-0 (cluster 1 primary core).

    Vijay Kumar Arwapally said:

    All the above projects would have there individual syscfg files.

    1. Should there be any common cfg in all the syscfg files?(clk, mem etc?)

    In lockstep mode, the secondary cores (R5FSS0-1 and R5FSS1-1) operate as lockstep companions and do not run independent software. Therefore, only one application per cluster needs to be built. The SBL loads the application images for both clusters during boot.
    An additional “umbrella project” is not strictly required unless your build system needs one to orchestrate building multiple images together.


    Each project (SBL, Cluster0, Cluster1) typically has its own SysConfig file, because the configuration scope differs.

    However, some configuration should remain consistent across projects:

    Common configuration that can match

    • Device clock configuration (unless intentionally modified by SBL)
    • Pinmux configuration (if shared)
    • Memory region definitions used by linker
    • Peripheral instance usage assumptions

    Configuration that differs

    • CPU/cluster selection
    • Interrupt routing
    • Peripheral ownership
    • Linker memory allocation
    • RTOS configuration
    Vijay Kumar Arwapally said:
    Can the same peripherals be configured in both clusters?

    In general:

    • A peripheral should be owned and configured by only one cluster.
    • Both clusters should not independently configure the same peripheral instance, as this can cause register conflicts.
      However, the other cluster can still access data via IPC or shared memory mechanisms if required

    Typical approaches include:

    • Assigning specific peripherals to each cluster
    • Using shared memory or IPC for coordination between clusters
    Vijay Kumar Arwapally said:
    Any guide to migrate to CMake style build?

    Currently the MCU+ SDK build system is based on GNU Make, and the SDK examples are structured around that infrastructure. There is no official CMake-based build framework provided with the SDK at this time. However, customers who want to integrate with a CMake workflow typically do one of the following:

    1. Use CMake as a top-level build orchestrator and call the SDK makefiles for each project.
    2. Replicate the include paths, compiler flags, and library links from the example makefiles into their own CMake scripts.

    The SDK examples can be used as a reference for:
    • Required compiler flags
    • Library dependencies
    • Include paths
    • Linker command files

    Regards,
    Shaunak