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.

  • TI Thinks Resolved

TMDXIDK5718: Single image for all cores

Intellectual 485 points

Replies: 18

Views: 570

Part Number: TMDXIDK5718

Hi,

I am working on AM5718IDK, I have built the individual projects for each core(A15,M4,DSP). RTOS for A15, Bare-metal project for M4 and DSP.

Could you please answer my below queries:

1. Now I want to known the procedure for grouping 3 images together to load the final image on to eMMC or SD card.

I gone through the http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#system-integration document but it's only telling how to load the image from linux OS in run time.

2. Could you please tell me the how DDR partitions should be for each individual core images, as how should be the memory mapping

3. Is Bare-metal OSAL delay timers simultaneously work on all cores at the same time?

4. What is difference between OSAL Bare-metal library and CSL Libraries.

Regards,

Naveen.

  • HI Naveen,

    1. Please see the following http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_00_00_07/rtos/index_Foundational_Components.html#am57x.

    2. For details on memory partitioning in RTOS, please see: http://software-dl-stage.itg.ti.com/public/hpmp/software/app_dev_procsdk_rtos/presentation_html5.html, Section 10.8. You can use this approach to setup the memory partitioning for your system. The A15 application build will result in a linker command file which is used as input to the GCC linker. The syntax for this file will be for GCC, but it can be used as a starting place for creating linker command files for other cores using different toolchains (e.g. C66x).

    3. Yes, Bare-metal OSAL timers can be used simultaneously on each core. Each timer it mapped to an independent, core-specific timer.

    4. The non-OS OSAL is basically a wrapper for CSL code. It's recommended to use OSAL so the same code can be ported to a use case requiring OS services. More information on this is here: http://software-dl-stage.itg.ti.com/public/hpmp/software/intro_procsdk_rtos_p2/presentation_html5.html, Section 9.

    Please let me know if your issue is resolved.

    Regards,
    Frank

  • In reply to Frank Livingston:

    Hi Frank,

    Thanks for the quick reply, I am unable to open the links mentioned in 2 and 4 points, can you share the document.

    And I have one question regarding the usage of osal delay timers, I have loaded bare-metal applications on M4(IPU1_C0), DSP and A15 is in suspend state only(no code is running on A15).

    The M4 is initializing the peripherals (uart, i2c, spi, gpio) and pad configurations as mentioned below:

    And I am able to use osal delay function in M4 and DSP cores without any problems when they are running individually.

    When I am trying to use both cores at the same time with osal delay functionality, I am facing problems, DSP it's not able to set the interrupt and waiting in the infinite while loop(osalTimerDelay, added below code snapshots for reference). As M4 initializing the board as mentioned above, in DSP I am not doing any board or peripheral initialization, if I am trying to do the same it's stuck at Board_init I don't know exact issue where it actually stuck. So I am directly creating the timer and using the delay function inside the main function in DSP.I am running the M4 core first then running DSP core afterwards.

    What I am doing wrong, should I have to initialize the board config and peripherals from A15 only? and this OSAL is software or hardware timers?  And I am using GPTIMER5 for DSP and GPTIMER9 for M4 cores.

    Regards,

    Naveen.

  • In reply to Naveen B:

    Hi Naveen,

    Please see if you can access these links:

    https://training.ti.com/application-development-using-processor-sdk-rtos

    https://training.ti.com/introduction-processor-sdk-rtos-part-2

    You can also get to this information as follows:

    • www.ti.com, click on Support & training
    • Click on Online training tutorials
    • Select "Tools & Software"
    • In filter, type "am57 rtos"
    • Browse to presentations

    >>should I have to initialize the board config and peripherals from A15 only?

    Normally the system master should be the only core which calls Board_init(), and this should be the case for your final multi-core application. However, it should be OK to call Board_init() from the M4 and not the DSP during intermediate application development involving the M4 & DSP cores.

    Using OSAL timer from your M4 & DSP bare metal applications should be OK. It may be there's some resource contention. Would it be possible for you to share an example project which demonstrates the problem?

    Regards,
    Frank

  • In reply to Frank Livingston:

    Dear Frank,

    I am using the bare-metal template applications available at C:\ti\processor_sdk_rtos_am57xx_6_00_00_07\demos\rtos_template_app\am572x\evmAM572X\M4\template_app\baremetal and C:\ti\processor_sdk_rtos_am57xx_6_00_00_07\demos\rtos_template_app\am572x\evmAM572X\C66\template_app\baremetal folders.

    I just modified the libraries file paths to idkAM571x and changed the GPIO_idkAM571x_.c file. Please let me know if you need any further details.

    Regards,

    Naveen.  

  • In reply to Naveen B:

    Naveen,

    Thanks for the details on example applications. I'll experiment with the code and get back with you.

    BTW I discovered that the above links were broken outside TI. They should work now:

    https://training.ti.com/application-development-using-processor-sdk-rtos

    https://training.ti.com/introduction-processor-sdk-rtos-part-2

    Regards,
    Frank

  • In reply to Frank Livingston:

    Dear Frank,

    Have you figured out the problem?

    Regards,

    Naveen.

  • In reply to Naveen B:

    Hi Naveen,

    We had some severe weather problems here, so my investigation was slowed down quite a bit. I'll take a look at this tomorrow. Thanks for your patience.

    Regards,
    Frank

  • In reply to Frank Livingston:

    Hi Naveen,

    I took at look at the template apps. I noticed the following note in http://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_01_00_08/rtos/index_examples_demos.html?highlight=rtos_template_app#connecting-to-the-target:

    Do not attempt to load and run the template application on two cores simultaneously as the Template Application is not designed to run this way.

    I experimented with loading & executing the M4 & C66 cores with these apps, and I obtained results similar to those you've observed for Board_init() included & excluded from the C66 code.

    Looking through the code, I see:

    • The same I2C, GPIO, and UART are used on both the M4 & C66 cores.
    • The SPI task is only stubbed out, and no transactions take place over SPI
    • A different timer is used on the M4 & C66 cores to implement the OSAL timer. M4 uses GP Timer 3, while C66 uses GP Timer 4.

    It seems like the only way these bare metal apps might simultaneously execute on the M4 & C66 cores is if:

    1. Board_init() & I2C EEPROM read are left in the code for one core and removed from the code for the other core.
    2. GPIO is remapped in the code for one of the cores.
    3. UART is remapped or removed from the code for one of the cores.

    The GP timer is the only hardware which appears to be a physically distinct in the code for each core, so it seems like the code on each core should be OK to use the OSAL timer functionality without any modifications.

    Have you modified the code to only use the GP timer functionality? If you've performed this experiment and are having problem with the GP timer on one of the cores then there might be a problem with OSAL TimerP which needs further investigation.

    Regards,
    Frank

  • In reply to Frank Livingston:

    Thanks for your reply Frank,

    I am performing the board initialization in M4 core only, in DSP core I am directly using the timers without any board initialization and I2C, UART, GPIO initialization's. I have commented the board_init() function, peripheralInit() functions and all i2c, gpio, uart tasks inside the appRunTasks() function in DSP core. The first block of code which will be executed inside the DSP core is as below:

    Once it's reaches the osalTimerDelay() function, it's got stuck in delayTimerFlag check. As the description in below function says failing to trigger ISR.

    Please let me know what are the changes I need to do?

    Regards,

    Naveen.

  • In reply to Naveen B:

    Naveen,

    Thanks for the update, and sorry for the delayed response. I'll try to reproduce this issue and get back with you by the end of the week.

    Regards,
    Frank

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.