• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 84 subscribers
  • Views 457 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.

F29H85X-SOM-EVM: the usage of sysconfig in triple cores

Jenney Ni
Intellectual 1950 points

Part Number: F29H85X-SOM-EVM
Other Parts Discussed in Thread: SYSCONFIG

Hi all,

We have encountered some Syscfg-related issues during multi-core development with the F29x series. 

Background:
We need to utilize all three CPUs on the F29 device, so we have set up a tri-core project. CPU1 is developed based on MCAL and does not require Syscfg, so we have excluded it from the build in this project (enabling it would cause conflicts between the generated code and the MCAL code, leading to compilation failures).
CPU2 and CPU3 are developed based on the SDK and require Syscfg for the configuration of GPIO, ADC, etc.

Issues:

  1. In a multi-core project, if CPU1/CPU2 need to use GPIO, configuration must be performed via Syscfg in the CPU1 project. This conflicts with our development scenario and causes compilation errors for CPU1.
  2. Similarly, if CPU2/CPU3 require ADC functionality, configuring ADC via Syscfg for CPU2 requires additional configuration of ASYSCTL and ANALOG PinMux in CPU1's Syscfg. This does not fit our use case, as we do not need Syscfg for CPU1.
  3. If we exclude Syscfg from the build in CPU1's project, Syscfg code will not be generated for CPU2/CPU3 either, indicating that the three cores share a linked Syscfg configuration.

Given the above, how can we achieve independent Syscfg configurations for CPU2/CPU3 (SDK-based) while completely excluding Syscfg from CPU1 (MCAL-based), to meet our application requirements?

Note: We use the example of SDK ‘led_ex2_blinky_cpu1_cpu2_cpu3_multi’ .

C:\ti\f29h85x-sdk_1_01_00_00\examples\driverlib\multi_core\led\led_ex2_blinky_cpu1_cpu2_cpu3_multi

Regards,

Jenney

  • 0
    TI__Mastermind 20475 points

    Hi Jenney,

    I am looking into this and will get back to you as soon as possible. 

    Best Regards,

    Aishwarya

  • 0
    TI__Mastermind 20475 points

    Jenney,

    Please note that GPIO, Asysctl, Analog, and Pinmux code must be run from CPU1 which is why we have them in the CPU1 SysConfig context.

    I would suggest using the Resource Allocator module which was designed for this exact use case. There are examples within the various SDK folders and more information here: Resource Allocator Module — Documentation for F29H85x

    Best Regards,

    Aishwarya

  • 0 in reply to Aishwarya Rajesh
    TI__Intellectual 1950 points

    I don't quite understand the role of the Resource Allocator Module for the current issue. I understand MCAL will still generate the corresponding code as before, so won't that still conflict with the SDK code?

  • 0
    TI__Mastermind 20475 points

    Jenney,

    Looping in some team members to help with this question.

    Best Regards,

    Aishwarya

  • 0 in reply to Aishwarya Rajesh
    TI__Intellectual 2716 points

    Hi Jenny, 

    Since GPIO can only be configured by CPU 1, you can configure pins for all three CPUs in CPU 1. To configure GPIO you can use the PORT module from the MCAL. There is no need to use SysConfig for CPU, it has to be purely EB Tresos based config for MCAL. 
    Configurations such as ANALOG pins exit in EB Tresos for CPU 1 MCAL: 

    The same applies for ASYSTAL as well. Within the Cdd_Adc in EB Tresos, you can find the same options as SysConfig: 

    All GPIO configs can be done in EB Tresos via CPU 1 and later used in CPU2/3.

  • 0 in reply to Pranav Siddappa
    TI__Intellectual 1950 points

    Hi Pranav，

    What you mean is: the conflicting parts all have corresponding configuration options in EB tresos. You only need to complete those configurations in EB on CPU1, then CPU2/CPU3 can use them directly.

    However, after excluding the syscfg build in CPU1, CPU2/CPU3 will no longer generate the related code. In that case, will like the ADC-related code configured through SysConfig on CPU2 still be generated?

    If it cannot be generated, then do the related configurations on CPU2 need to be initialized by manually calling the initialization APIs?

    If it can be generated, does that mean there is something wrong with my project/code generation setup? Do we have any similar multi-core examples that i can refer to?

    Regards,

    Jenney

  • +1 in reply to Jenney Ni
    TI__Intellectual 2716 points

    Hi Jenny, 

    Jenney Ni said:
    What you mean is: the conflicting parts all have corresponding configuration options in EB tresos. You only need to complete those configurations in EB on CPU1, then CPU2/CPU3 can use them directly.

    Yes, you can configure them in CPU 1 via EB Tresos and use them in CPU2/3. 

    Jenney Ni said:
    If it can be generated, does that mean there is something wrong with my project/code generation setup? Do we have any similar multi-core examples that i can refer to?

    You can refer to the multicore SPI example (Spi_Example_External_Loopback) in our F29x MCAL. It has MCAL on CPU 1 and SDK on CPU 3.

    Regards, 
    Pranav Siddappa

  • 0 in reply to Pranav Siddappa
    TI__Intellectual 1950 points

    Hi Pranav,

    The code of CPU3 was generated by the sysconfig? 

    If yes, how to configurate CPU3 without CPU1 by the sysconfig?

    Regards,

    Jenney

  • 0 in reply to Jenney Ni
    TI__Intellectual 2716 points

    Hi Jenny,

    You can refer to the SPI External Loopback example for this. I have also attached a screenshot of window within syscfg where you can select CPU3.



    Regards,
    Pranav Siddappa