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.

LAUNCHXL-F28379D: Dual Core application

Part Number: LAUNCHXL-F28379D
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I want to do a dual core application, and I did not know where to start (please tell me if there is a "getting started" document)

So I import the 2 examples provided on the web site:

LED_ex1_Blinky:

When I load the cpu1.obj into the micro controller, the first LED is blinking. But when I load the cpu2.obj, neither LED1 nor LED2 is blinking.

What is the protocol to load the programm into the micro controller ?

LED_ex2_SysConfig:

After importing the example, I see 3 projects: CPU1, CPU2 and multi.

Only the multi project can be loaded into the Microcontroller.

What is the way to create a such project ?

When looking at the sysconfig files, I saw that this files are different condering the core. For instance, there is no GPIO section for CPU2.

How do we make a sysconfig condidering the core capability ?

Also, I did not see any linker command files in the 3 projects. Why ?

Also, there is no RAM configuration for this example. Does TI provide any exemple with RAM configuration ?

Thank you.

  • Hello Vincent,

    I want to do a dual core application, and I did not know where to start (please tell me if there is a "getting started" document)

    Unfortunately there is no specific document outlining getting started with a dual-core device. What you did by importing the dual-core example is what we typically recommend.

    What is the protocol to load the programm into the micro controller ?

    The procedure is to first program CPU1 and then CPU2; in a debug session, this would be done by starting a debug session on the CPU1 project, loading that .out file to the device, and then loading the CPU2 .out file. Let me know if you're using a specific method to program the device or if you're just using a normal debug probe.

    What is the way to create a such project ?

    When looking at the sysconfig files, I saw that this files are different condering the core. For instance, there is no GPIO section for CPU2.

    How do we make a sysconfig condidering the core capability ?

    Also, I did not see any linker command files in the 3 projects. Why ?

    Also, there is no RAM configuration for this example. Does TI provide any exemple with RAM configuration ?

    I will redirect these questions to the SysConfig multi-core expert.

    Best regards,

    Omer Amir

  • Vincent,

    The 'multi' project is just used to keep the core1 and core2 projects linked. This project is necessary to keep the sysConfig files linked, you can also use it to make settings for the other two projects, and you can build only the 'multi' project and it will build the two linked projects.

    While you can use the debug button with dual-core projects, I would recommend the following steps:

    View Target Configurations- -> Right-click and Launch your target configuration -> Connect to each CPU core -> load to CPU1 then CPU2

    Please let me know if you have any questions about this.

    What is the way to create a such project ?

    I would recommend starting with the empty project, or editing one of the multicore sysconfig examples. If you change the names of your projects, you will have to change the names in the 'multi' system.xml file for the projects to remain linked.

    How do we make a sysconfig condidering the core capability ?

    I'm not sure what you mean by this, could you please clarify? 

    Also, I did not see any linker command files in the 3 projects. Why ?

    The linker command files are being generated by SysConfig. You can see the CMD module in SysConfig. If you want, you could remove this module and copy/paste the default linker command files into your projects.

    Also, there is no RAM configuration for this example. Does TI provide any exemple with RAM configuration ?

    In the linker command sysconfig module, you can simply click on the setup default ram, and that should configure your programs to be loaded into RAM. You will need to do this for both CPUs.

    Please let me know if I can answer any further questions for you.

    Best Regards,

    Ben Collier

  • Hello, first thank you for your answer, and sorry to reply with that delay. I could nt do faster. Sorry.

    I re loaded the example from your cloud.

    When loading the multi project into the micro controller, any LED is not blinking. I think it is the first step I have to check before I can go further.

    I tried to follow th method you recommand:

    1- View Target Configuration

    2- Right Click --> sorry but I don't know where. I expected to see a configuration for the multi project but the option "launch selected" is available only for the CPU1 por CPU2 project.

    Can you explain to me, step by step:

    - how to load the multi project into the micro controller and verify that the 2 leds are blinking

    - how to debug the multi project

    Thank you.

    Vincent

  • Vincent,

    I will be able to provide some more detailed instructions tomorrow. The target configurations are the same for CPU1 and CPU2, so you can launch either of them.

    This should open the debug menu, then you should be able to right-click on the C28xx cores, and connect to CPU1 and then connect to CPU2. 

    Then you can click on CPU1, then click on the load button, and select your .out file for CPU1. Then you can click on CPU2 in the debug menu, then click on the load button, and select your .out file for CPU2. 

    This thread may also interest you: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1293332/tms320f28379d-debugging-auto-connect-and-flashing-of-all-cores

    Best Regards,

    Ben Collier

  • Vincent,

    Sorry for the delay. I was going to leave some step by step instructions to manually build and load programs onto CPU1 and CPU2, but I think it may be better in the long term if you follow the instructions from the thread linked above. This way you will be able to just click the debug button to build and load your projects, rather than manually going through each step as I was describing above.

    Best Regards,

    Ben Collier

  • Hello Benjamin.

    Thanks to the thread you sent me, I managed ti blink the led on the dual core .... but only in the debug mode. First I want to be sure I am doing it right, then I want to do learn how to load the programm in the release mode directly. Can you look at what I did, below.

    Debug mode:

    - I selected the multi cores project, then entered in the debug mode

    - in the debug configuration, I ask to load the output file of _cpu1 project in the CPU1 core, and the output file of the _cpu2 project in the CPU2 core

    first question: why are these informations not saved in the multicore project I want to debug ?

    - Then I run the two programms to see the led blinking

    Is that the right way to debug the multi cores project ?

    Release mode:

    So now I want to load the project into the µC, and see the led blinking without the micro controller is linked to my PC.

    - I select the multi core project

    - I ask to load the output of this project into the µC. I guess CCS will load the output of the _cpu1 project into CPU1 and the output of the _cpu2 project into CPU2, because it is explained in the the core projects section

    By this way, no LED is blinking !!

    How can I do to load the programm into the cores using the _multi project and the "load" icon? It has to be usefull for something ?!

  • Hi Vincent,

    first question: why are these informations not saved in the multicore project I want to debug ?

    I do not understand what you mean by this, could you explain? Are the debug configuration settings not being saved in your project? 

    How can I do to load the programm into the cores using the _multi project and the "load" icon? It has to be usefull for something ?!

    Are you able to use the debug button with the _multi project to build and load your code? I have not actually tried this, I have only set up the debug configurations for _cpu1 and _cpu2. 

    Really the main purpose of the _multi project is that it links the sysconfig files from the other two projects. There are also some small benefits, like setting a build configuration for the _multi project will affect the build configuration for both _cpu1 and _cpu2 projects.

    So now I want to load the project into the µC, and see the led blinking without the micro controller is linked to my PC.

    Please make sure that your boot pins are set up for boot to flash mode. Also please see point number 2 from this post: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1204669/launchxl-f28379d-can-t-run-dual-core-sysconfig-project-in-standalone-mode

    This line is needed when using CPU2 in standalone mode, unfortunately it is missing in our F2837xD SysConfig examples. We are planning to add it in an upcoming release.

    Best Regards,

    Ben Collier

  • Hello Benjamin,

    I am disappointed because each time I ask something in this forum, each time the answer is "take an example provided on our website". But the examples have never have the same structure (for the 379D)  and things are missing.

    Do you agree to spent time to help me, step by step? This issue is serious for my company. We have to understand how to manage a dual core project.

    What I propose to you is to start form the led blinking example 2 (the example I consider as the cleanest one)

    Step 1: to make the programm running in the debug mode

    Are you able to use the debug button with the _multi project to build and load your code?

    Not always.

    What seems to work:

    I select the FLASH configuration in the multi core project and enter in the debug mode.

    Doing this,  _cpu1 project is not ask as loaded in CPU1 and _cpu2 project is not asked as loaded in CPU2. The _multi project is loaded in each CPU (but I guess it does the same)

    Then I can run the first project, then the second one, and see the led blinking.

    What seems to not work:

    I did the same thing the the RAM configuration but the run is suspended:

    So, the first issue to resolve is: how to make the RAM configuration work ?

    Step 2: to understand the Command linker files

    I was surprised not to see any command file in the projects. In another post, someone exmplained to me that the command file is generated by SysConfig.

    But I still wonder how the project understands that the command file to take into account is this one, because in the proporties, the appropriate field is empty:

    So, I guess that the project takes into account the only command file which is available.

    But, what will happen if I add another command file into the project ? (typically for bit fields) Does the compiler take the wrong file into account ?

    Step 3: Standalone mode

    Please make sure that your boot pins are set up for boot to flash mode

    I must say that I never looked at the DIP switches since now.

    I ve seen that it sets the  GPIO 84 and 72, which determines the boot mode.

    In the SPRUH8MJ I saw this table:

    I cannot read any information on the way to boot on the RAM in this table. On my launchXL, every switch is held on the probe side, and every thing was fine.

    It is the position I have to choose to a dual core project in a stand alone mode ?

    I also read the thread you sent to me.

    I always read the code lines you inserted, in another example, and pasted the same:

    as you can see, this code is more detailled than yours, but deals with the _STANDALONE macro.

    Where have I to define this macro ? only at the top of source code in the _cpu1 project ?

    I also change the code start :

    Do I have to do that each time I want to run the µC in the FLASH (it worked in the debug mode without any change) or just in the standalone mode ?

    It is not simplier not to re-generate the command files by SysConfig ? (as we did in the signle core applications)

    I tried to load the _multi project (fingers crossed) but nothing happend.

    I join an archive of this exemple. I spent time to write this reply, I hope you will help me. Feel free to modify the project, and join it to your reply.

    2023_12_14_2Send2TI.zip

  • Vincent,

    Step 1: 

    Debug configurations do not exist for a given project until you try to use the debug button for that project. At that point, CCS will create a debug configuration for that project that you can edit in the debug configuration settings. By default, the 'Project' entry will be the project that you are trying to debug, and the 'Program' entry will be the build_artifact (.out file) from that project.

    I have just learned that the default debug configuration for a project that contains a 'system.xml' file will actually use the system.xml file to assign a project to each one of the CPU cores. If you open the system.xml file in the multi project, you can see which project is assigned to each CPU. You can also edit the build configuration setting for the project here, but as you probably found out, the build configuration settings don't make the code load to flash.

    Step 2: 

    I switched the build configuration to RAM, and I didn't encounter a problem. The projects, however, were still built and loaded to FLASH. This is because the linker command files are generated by SysConfig and are set to FLASH. If you go to each linker CMD module and click the 'SETUP RAM DEFAULT' under Default configuration, then your program will be loaded to RAM. 

    When the linker command sysconfig module is enabled, a file called device_cmd.cmd.genlibs defines "CMDTOOL" as well as the name of your linker CMD settings. You need to make sure that this check box is clicked: 

    If the checkbox is not clicked, CMD0 (name of these linker command settings) will not be defined and the linker command tool functions will not do anything. 

    I believe that as long as a file that ends with '.cmd' is included in your project build, the compiler will treat it as a linker command file. If you try to add another linker command file without removing the linker command tool, you will encounter errors since the same memory will be used multiple times. The compiler will treat both linker command files as valid, and it will pretty much combine them. If you want to use a different linker command file, you should be able to simply copy and paste it into your projects, and then uncheck the 'Active Linker CMD Configuration' box.

    Step 3: Standalone mode

    There is no boot to RAM mode since RAM is empty after a power-on reset. If you want to run code from RAM, it must be copied into RAM from FLASH (this is done for some FLASH initialization functions by default in device_init() function). 

    It is the position I have to choose to a dual core project in a stand alone mode ?

    You have to boot to flash if you want to run code from flash. If you choose one of the other boot modes that are selectable from that DIP switch, the device will wait in boot ROM indefinitely. 

    as you can see, this code is more detailled than yours, but deals with the _STANDALONE macro.

    Where have I to define this macro ? only at the top of source code in the _cpu1 project ?

    In some other projects, I believe this is handled with a build configuration. When you select the 'STANDALONE' build configuration, this is defined. FLASH is also defined when you pick the flash build configuration. There are many ways you can handle this, but the examples will not run with default settings if you leave this in your code when your debug probe is connected. This function will wait for something to happen that would only happen if the device went through the boot ROM normally, which will not happen when your code is loaded and you jump to main.

    I tried to load the _multi project (fingers crossed) but nothing happend.

    The only edit I had to make for the project to run in standalone mode was to add this line on CPU1 somewhere above the ipc sync function: Device_bootCPU2(C1C2_BROM_BOOTMODE_BOOT_FROM_FLASH);

    Again, this function will make it so that your code WILL NOT work if you load it from the debug probe and jump to main. 

    Best Regards,

    Ben Collier

  • Hello Benjamin,

    Just a word to thank you for these explanations. I had no time enough the days to try everything, but I think this will help me.

    I will come back to you in 2024.

    So, I wish you ll envoy the celebrations. Have a merry Christmas.

    Vincent.

  • Merry Christmas Vincent! I look forward to continue working with you.

  • Hello Benjamin,

    First, I wish you an happy new year.

    I m back to work. I think I understood several things by reading your last answer. It does not work on my board, but now I think it will be easy to find the mistake I m doing.

    My goal is to be able to do step 2, as you did (load RAM or FLASH configuration, even if the programm is loaded into FLASH for each configuration)

    1) I create a new workspace and load the example provided on the ressource explorer

    2) looking at the system.xml file in the multi project I can see that:

    -  the xxx_cpu1 project will be executed by CPU1

    - the xxx_cpu2 project will be executed bu CPU2

    3) looking at the SysConfif File for each project, I see that the code start section is defined in the RAMM, which I don t understand

    4)  In the xxx_cpu1.c file, I put the Device_bootCPU2 function

    5) I click on the "flash" icon, after selecting the multi project

    CCS loads the xxx_cpu1 project --> I see the blue led blinking

    CSS loads the xxx_cpu2 project --> no led is blinking

    6) I generated the FLASH setup default for each CPU:

    So the code start is defined in the FLASH --> it does the same.

    Questions:

    - where do I make a mistake ?

    - why do we talk about project loaded in one of two CPU ? In my opinion, the project is loaded into the unique FLASH. The CPU1 boots , and its first function is to say to the CPU2 to boot on an other adresse of the FLASH

    - what does the probe in the debug mode for a RAM configuration? (does it load the programm into the defined RAM ?) 

    - what does the probe in the debug mode for a FLASH configuration ?

    Thank you.

    Vincent

  • Hi again Vincent,

    I will need a day or two to put together another detailed response for you.

    Best Regards,

    Ben Collier

  • Vincent,

    I think that there are two things that are possibly wrong for you .

    1) If you are trying to load your program to flash, you need to click on the SETUP DEFAULT FLASH button in the cmd module: 

    2)  Device_bootCPU2 function will block your program when loaded from the debug probe. For this function to work correctly, the device needs to go through the normal boot ROM flow, which does not happen with the debug probe connected

    If you fix these and still get stuck, please halt your program and tell me where you are in the program.

    Best Regards,

    Ben Collier

  • Hello Benjamin,

    I already did the changes you mentioned. It did not work, but I changed something else this morning: the place I call the DeviceBootCPU2

    It works (after set the DIP switches into the right positions), but I don't know why. Can you tell me why ?

    There is also a question, important for me:

    why does his fonction block the programm using the debug session ? I am sure I missed something.

    For me:

    - the debug probe connects to CPU1, and loads the programm for this CPU into its FLASH

    - then the debug probe connects to CPU2, and loads the programm for this CPU into its FLASH

    - by clicking on the green arrow for CPU1, I ask for the CPU1 to run, i.e. to execute the code from its FLASH: one of the first instruction is to ask to CPU2 to boot from its FLASH

    - by clicking on the green arrow for CPU2, I ask for the CPU2 to do so.

    The reason the programm does not work is that CPU1 asks to CPU2 to boot from FLASH while CPU2 is blocked by the JTAG ?

    What does exactly the JTAG for CPU1 ? Am I right below ?

    - loads FLASH utility and FLASH data into the RAM

    - ask to CPU1 to execute FLASH utility. The CPU1 writes FLASH Data into its Flash

    - ask to CPU1 to launch the programm and to stop to main ?

    Finally, I have 2 more questions about SysConfig:

    1) It is possible on the IPC menu for CPU1 to select the boot for CPU2. But by cliking on the interrogation mark, CCS says that the Device_bootCPU2 function is still needed.

    what is the purpose of this option ?

    what happens if we choose "Boot from RAM" but define Device_bootCPU2(C1C2_BROM_BOOTMODE_BOOT_FROM_FLASH); in the code ?

    2) the 2 projects xxx_cpu1 and xxx_cpu2 contains their own SysConfig file: 

    But whatever is the file I click on, CCS opens the ccpu1 SysConfigFile, switching the CPU in the SysConfig plugin:

    Can you explain that ?

    After I will understand that, I think I will be able to manage FLASH and RAM configurations, in debug or standalone mode.

    Thank you

  • Vincent,

    I already did the changes you mentioned. It did not work, but I changed something else this morning: the place I call the DeviceBootCPU2

    It works (after set the DIP switches into the right positions), but I don't know why. Can you tell me why ?

    I am not sure why the placement of the bootCPU2() function matters for you. It works for me so long as it is placed somewhere between device_init() and IPC_sync().

    why does his fonction block the programm using the debug session ? I am sure I missed something.

    The reason the programm does not work is that CPU1 asks to CPU2 to boot from FLASH while CPU2 is blocked by the JTAG ?

    What does exactly the JTAG for CPU1 ? Am I right below ?

    - loads FLASH utility and FLASH data into the RAM

    - ask to CPU1 to execute FLASH utility. The CPU1 writes FLASH Data into its Flash

    - ask to CPU1 to launch the programm and to stop to main ?

    The way the function is written, CPU1 will wait until CPU2 reaches a certain place in the boot ROM flow, then it tells CPU2 how to continue. When the debug probe loads the code, these boot ROM steps are bypassed by both CPU1 and CPU2. CPU1 will then wait forever for CPU2 to reach a place in boot ROM that it will never reach.

    Your understanding is pretty much correct. CPU1 does not run to main, however, but jumps to main (program counter is changed). This is the same for CPU2.

    1) It is possible on the IPC menu for CPU1 to select the boot for CPU2. But by cliking on the interrogation mark, CCS says that the Device_bootCPU2 function is still needed.

    what is the purpose of this option ?

    what happens if we choose "Boot from RAM" but define Device_bootCPU2(C1C2_BROM_BOOTMODE_BOOT_FROM_FLASH); in the code ?

    All this does is #define a term in board.h that is called something like CPU2 BOOT MODE. So the functionality is fairly limited, nothing will happen if you do not use that term. 

    2) the 2 projects xxx_cpu1 and xxx_cpu2 contains their own SysConfig file: 

    But whatever is the file I click on, CCS opens the ccpu1 SysConfigFile, switching the CPU in the SysConfig plugin:

    Can you explain that ?

    Honestly I am not sure how this works, this functionality is embedded into CCS. All I can tell you is that the system.xml file tells CCS that the SysConfig files are linked, so that they both open when you click on one of them. You can see this if you open system.xml with a text editor.

    Is this a problem for you, that CPU1 is the sysconfig file that is opened by default? 

    Best Regards,

    Ben Collier

  • I am not sure why the placement of the bootCPU2() function matters for you. It works for me so long as it is placed somewhere between device_init() and IPC_sync().

    When I put the BootDevice function after Interrupt_initVectorTable();, this message appears when loading the programm:

    Also, only the CPU1 is working (blue led is blinking)

    When calling the CPUBoot function anywhere above Interrupt_initVectorTable(), everything is OK

  • Vincent,

    I had misremembered my work from before the holidays. I actually put the bootCPU2() function right after Device_bootCPU2(). It also does not work for me if I put the function after Interrupt_initVectorTable().

    I do not know why your project is only working for CPU1. I have attached my project, which works for CPU1 and CPU2.

    led_ex2_sysconfig_cpu1.zip

    Best Regards,

    Ben Collier

  • Benjamin,

    Maybe I was not clear enough (you certainly noticed my broken englsh): CPU1 AND CPU2 are OK for me if I put the function before Interrupt_initVectorTable(), just like you.

    But I wonder why. Can you tell me ? Does this function need a flag which is erase by Interrupt_initVectorTable() or something like that ?

    After you will answered to me, I propose to close this issue, to start to work, and if I have another problem on the 2 cores managment, to open a new thread. Are you OK with that ?

  • I will need a few days to see if I can find an answer for this. 

  • Hey Vincent,

    If you take a look inside the Device_bootCPU2() function, you will see that it uses IPC flag 31. If you switch to using another IPC flag for the SYNC function, you can place the Device_bootCPU2() flag anywhere before the IPC sync function.

    Best Regards,

    Ben Collier

  • do you mean that Device_bootCPU2() waits for flag 31 baut does not reset it ? And that  Interrupt_initModule() does reset all the flags instead ?

  • CPU2 seems to acknowledge the Flag31 ... I m certainly wrong

  • Vincent,

    It looks like CPU2 to CPU1 IPC_FLAG31 and IPC_FLAG0 are already high whenCPU1 reaches the IPC_sync() function, which causes CPU2 to get stuck at the IPC_sync() function.

    I think you could solve this problem by clearing all of the flags before the sync function, or you could use a different IPC_sync flag.

    Best Regards,

    Ben Collier

  • Hello Benjamin.

    Thank you for your explanation.

    I was wrong, actually CPU1 never acknowledge the Flag 31.

    I closed the threads.

    Vince