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.

RTOS/TMDX654IDKEVM: Problem with running SMP

Part Number: TMDX654IDKEVM
Other Parts Discussed in Thread: AM6548, , SYSBIOS

Tool/software: TI-RTOS

Hello All,

I have a problem with running SMP on AM6548.

My configuration is:

CCS ver 8.3.0
PDK - pdk_am65xx_1_0_4
AM65x (IDK) - TMDX654IDKEVM
SYSBIOS - 6.75.2.00

Because it doesn't exist any example for SMP in PDK, i made simple TI RTOS project in CCS with two tasks without SMP.
Then I build and test application, and everything works OK.

In purpose to see how SMP works and how to implement SMP to my application, I followed instructions from processors Wiki:

processors.wiki.ti.com/.../BIOS


I followed all steps from link above. I changed BIOS .cfg file like is described. In source file i put for first task to have affinity 0  and for second to have affinity 1.

I followed part for SMP debugging. I did create sync group and i load application. But app didn't start with execution. The application is stucked on address 0x70000000, without continuing with execution startup initialization (_c_int00():) and BIOS initialization.

processors.wiki.ti.com/.../Public_SmpBiosSlides.pdf

Maybe the problem is in gel file for A53 core. In document, from link above, is described that shared memory needs to be setup, but i didn't know how to do that in gel script file for A53 core.


I would be thankful and it will be great, if someone could provide some basic CCS example for SMP on A53 core with all necessary files (.cfg file for BIOS, .js script file or gel file for A53...). 

Best regards,
Novica

  • Hi Novica,

    Could you try this basic example.  Attached is the .cfg file and the .c file.

    /*
     * Copyright (c) 2015, Texas Instruments Incorporated
     * All rights reserved.
     *
     * Redistribution and use in source and binary forms, with or without
     * modification, are permitted provided that the following conditions
     * are met:
     *
     * *  Redistributions of source code must retain the above copyright
     *    notice, this list of conditions and the following disclaimer.
     *
     * *  Redistributions in binary form must reproduce the above copyright
     *    notice, this list of conditions and the following disclaimer in the
     *    documentation and/or other materials provided with the distribution.
     *
     * *  Neither the name of Texas Instruments Incorporated nor the names of
     *    its contributors may be used to endorse or promote products derived
     *    from this software without specific prior written permission.
     *
     * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
     * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
     * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
     * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
     * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
     * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
     * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
     * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
     * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
     * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
     * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
     */
    /*
     *  ======== TaskSetPriTest1.c ========
     *  Test Task_setPri() API
     *
     *  This test case creates 2 threads that are bound to core 0 (tsk0) and
     *  core 1 (tsk1) respectively. tsk1 is trying to set its own priority to
     *  '1' in an infinite loop while tsk0 is trying to set tsk1's priority to -1.
     *
     *  With older releases of BIOS, it is possible that both tsk0 and tsk1
     *  make Task_setPri() calls simultaneously and tsk0's setPri() instance
     *  acquires the scheduler lock first. tsk0 will then update tsk1's priority
     *  to '-1' (inactive) and release the scheduler so tsk1 can be preempted.
     *  However, since tsk1 is already in the process of acquiring a lock,
     *  it will not run the scheduler until it is finished updating the
     *  task priority to '1'. Therefore, tsk1 will exit Task_setPri() with a
     *  priority of '1' and never actually block.
     */
    
    #include <xdc/std.h>
    
    #include <xdc/runtime/System.h>
    #include <xdc/runtime/Types.h>
    #include <xdc/runtime/Timestamp.h>
    
    #include <ti/sysbios/BIOS.h>
    #include <ti/sysbios/hal/Hwi.h>
    #include <ti/sysbios/knl/Clock.h>
    #include <ti/sysbios/knl/Swi.h>
    #include <ti/sysbios/knl/Task.h>
    #include <ti/sysbios/knl/Semaphore.h>
    
    #include <xdc/cfg/global.h>
    
    Void tsk0_func(UArg arg0, UArg arg1);
    Void tsk1_func(UArg arg0, UArg arg1);
    
    /* Global Variables */
    Task_Handle tsk0, tsk1;
    
    volatile Bool exitFlag = FALSE;
    
    /*
     *  ======== main ========
     */
    Int main(Int argc, Char* argv[])
    {
        Task_Params taskParams;
    
        Task_Params_init(&taskParams);
    
        taskParams.priority = 2;
        taskParams.affinity = 0;
        tsk0 = Task_create(tsk0_func, &taskParams, NULL);
    
        taskParams.priority = 2;
        taskParams.affinity = 1;
        tsk1 = Task_create(tsk1_func, &taskParams, NULL);
    
        BIOS_start();
    
        return (0);
    }
    
    /*
     *  ======== idle_func ========
     */
    Void idle_func()
    {
        while (!exitFlag);
    
        BIOS_exit(0);
    }
    
    /*
     *  ======== tsk0_func ========
     */
    Void tsk0_func(UArg arg0, UArg arg1)
    {
        UInt i = 0;
    
        while (Task_getMode(tsk1) != Task_Mode_RUNNING);
    
        while (1) {
            i++;
            Task_setPri(tsk1, -1);
            if (i != 10000) {
                Task_setPri(tsk1, 2);
            }
            else {
                break;
            }
        }
    
        if ((Task_getPri(tsk1) != -1) || (Task_getMode(tsk1) != Task_Mode_INACTIVE)) {
            System_printf("Task_setPri() failed to make tsk1 inactive.\n");
        }
        else {
            Task_delete(&tsk1);
            System_printf("Test Passed!\n");
        }
    
        exitFlag = TRUE;
    }
    
    /*
     *  ======== tsk1_func ========
     */
    Void tsk1_func(UArg arg0, UArg arg1)
    {
        while (1) {
            Task_setPri(Task_self(), 2);
        }
    }
    

    TaskSetPriTest1.cfg

    Try building for the following platform:

    ti.platforms.cortexA:AM65X

    Let me know if you got any questions.

    Judah

  • Hi Judah, 

    Thank you for your response.

    I created CCS project with attached files (.cfg file and the .c file). Then i build CCS project without any error, only with some warnings.

    But when i tried to debug the same problem occurs, the app is stuck on _c_int00().

    I have created a video with screen capture to show what i did and what is the problem. 

    Once again thank you for your help.

  • I did use launch_am65xx.js from new PDK (pdk_am65xx_1_0_4).
    But maybe for SMP it need to be tell what regions of memory are shared between cores.
    Maybe we need to adapt GEL file for AM6548?

    Best regards,
    Novica

  • Novica,

    Your suggestion could be right.  I'm not familiar with the PDK but coming from the SYSBIOS side.
    I took a look at your video and its different how we start up our board.

    For us, we first connect to the DMSC_Cortex_M3_0 and that's the only core with a gel file specified.
    Once we connect to the DMSC, it runs the "OnTargetConnect()" gel function which sets up a bunch of stuff
    and then we can connect to the A53 cores.

    We use the gel file that comes with CCS located at:

    <CCS_INSTALL_DIR>/ccs/ccs_base/emulation/boards/am65x/gel/AM65xEVM.gel.

    We use the EVM board, probably not the same as the PDK?

    Judah

  • Hello Judah,

    Can you send me your AM65xEVM.gel and M4_R5orA53_Startup.gel files?

    I suppose when you tested SMP and when you tried to debug everything works OK. Did you test SMP on TMDX654IDKEVM (AM6548) board?

    I have Code Composer Studio Version: 8.3.0.00009. So maybe, in meantime, the GEL file was changed with new version of CCS.

    Novica

  • Update:

    In meantime i installed the new version of CCS (Version: 9.0.1.00004), and i tried to run SMP by using GEL files from this version, but at the end the result was the same.

    I compared the GEL files from CCSv9.0.1 and CCSv8.3.0, and I didn't notice that something has changed, the GEL files are the same in both version of CCS.

    BR,
    Novica