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.
TMDXIDK5718: Example projects
Part Number: TMDXIDK5718
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.
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.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Frank Livingston:
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.
In reply to Naveen B:
Please see if you can access these links:
You can also get to this information as follows:
>>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?
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.
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:
Have you figured out the problem?
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.
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:
It seems like the only way these bare metal apps might simultaneously execute on the M4 & C66 cores is if:
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.
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?
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.