TMDXIDK5718: Single image for all cores

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.

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

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.  

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

Dear Frank,

Have you figured out the problem?

Regards,

Naveen.

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

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

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.

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

Hi Naveen,

I've performed the experiments below while debugging this issue.

• #1: DSP only, original code. Result: Timer ISR fires.
• #2: DSP only, board & peripherals init, Timer only. Result: Timer ISR fires.
• #3: DSP only, board init & no peripherals init, Timer only. Result: Timer ISR fires.
• #4: DSP only, no board init & no peripherals init. Timer only. Result: Timer ISR doesn't fire.
• #5: DSP only, board init module clock only & no peripheral init. Timer only. Result: Timer ISR doesn't fire.
• #6: DSP only, board init all but UART stdio, no peripheral init. Timer only. Result: Timer ISR doesn't fire.
• #7: DSP only, board init UART stdio only, no peripheral init. Timer only. Result: Timer ISR fires.
• #8. Same as #7, but execute original M4 app before executing DSP app. Result: DSP Timer ISR fires.

For #6-#8, I can see the timer is executing by examining the TIMER5 TCRR in the memory map. However, Timer interrupts only occur for #7-#8.

Hence it appears OSAL timer interrupt configuration requires board init with UART stdio init. I'm investigating further, but this seems like a bug to me.

This is the code I have on the DSP for board init configuration:

    boardCfg = BOARD_INIT_UART_STDIO;

Regards,
Frank

Hi Frank,

I observed the similar behavior with CSL timer drivers also. I removed all the OSAL timer code and I integrated the CSL timer driver code, with the CSL timer code also I observed the similar behavior. My suspicion is should A15 only do the board initialization or initialization from any core is OK for multi-core applications? Usually SBL will do the board initialization, so I am doubting the board initialization procedure.

And I more doubt I have was, why the CSL i2c, uart libraries are depends on OSAL driver library file(ti.osal.aem4)? If I remove the OSAL library file, I am getting errors  as uart and i2c libraries are using some OSAL library calls. But when I inspect the OSAL library code it has the code related to timers only, so why this dependency?

And is OSAL library builds on top of CSL is it correct?

Regards,

Naveen. 

Dear Frank,

Small correction to my earlier post, with CSL timer libraries it's working. I think the problem is with OSAL timer libraries.

So, could you please answer my below questions:

1.  As I mentioned in earlier post why CSL uart and i2c libraries depends on OSAL library? As you mentioned earlier that OSAL is wrapper on CSL library, then why this dependency?

2.  If a peripheral is acquired by a M4, then what is the procedure for M4 to release the peripheral and DSP to acquire peripheral like UART.

Regards,

Naveen.

Hi Naveen,

>> My suspicion is should A15 only do the board initialization or initialization from any core is OK for multi-core applications?

A15 should be the only core performing board initialization for the final software, but board initialization can be used on other cores during intermediate development & debug of a multi-core application, e.g.:

• A15, M4 unused: DSP board init OK
• A15, DSP unused: M4 board init OK
• A15 unused: M4 board init OK, DSP no board init. This is our current use case, except that it appears the DSP OSAL timer requires Board_init() w/ UART_STDIO_INIT.

>> Usually SBL will do the board initialization, so I am doubting the board initialization procedure

Please see this section in the PRSDK documentation: http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_faq.html#secondary-bootloader

SBL calls the board library to set up the PLL clock, DDR, and Pin Mux, and to power on slave cores and the I/O peripheral from which it will boot the application. Excluding those just mentioned, any other configuration need to be done from the application code. As long as you have added all of the device initialization to the board library, you will not need to add any initialization code in the application.

>> CSL uart and i2c libraries depends on OSAL library?

The build errors you share above show the UART & I2C LLDs (Low-Level Drivers) depend on OSAL. However, the CSL (Chip-Support Library) libraries don't depend on OSAL. This can be seen by searching the CSL code base for "osal":

$ cd /r/pdk_am57xx_1_0_16/packages/ti/csl
$ grep -rI -n -i --regexp="osal" --include "*.h" --include "*.c" --include "*.asm" --exclude-dir="test" --exclude-dir="example" -l

soc/am571x/src/csl_a15_osal.c
soc/am571x/src/csl_a15_osal.h
soc/am572x/src/csl_a15_osal.c
soc/am572x/src/csl_a15_osal.h
soc/j721e/src/cslr_soc.h
src/ip/arm_gic/V0/csl_armGicAux.h

The CSL libraries are located in the pdk_am57xx_1_0_16\packages\ti\csl\lib folder, e.g. for AM571x & A15, see folder pdk_am57xx_1_0_16\packages\ti\csl\lib\am571x\a15\release, libraries are ti.csl.aa15fg & ti.csl.init.aa15fg.

>> As you mentioned earlier that OSAL is wrapper on CSL library, then why this dependency?

The dependencies are like this: LLD <-- (depends on) OSAL <-- (depends on) CSL

Please see this presentation for more details: https://training.ti.com/sites/default/files/docs/Application_Development_Using_Processor_SDK_RTOS_0.pdf, Slide 43/62.

>>  If a peripheral is acquired by a M4, then what is the procedure for M4 to release the peripheral and DSP to acquire peripheral like UART.

A general outline would be something like this:

1. M4 completes all outstanding transactions on peripheral.
2. M4 calls LLD close function for peripheral.
3. M4 notifies DSP that peripheral is available (using inter-processor communication).
4. DSP opens peripheral using LLD open function.

Step #2 & #4 may not be necessary since the M4 & DSP can both open the peripheral at the same time. As as long as only one core uses the peripheral at a particular time (one core "owns" the peripheral), then it should be OK for both cores to have the peripheral open from their local copy of the LLD at the same time.

If possible, it's probably better to statically partition peripherals for usage by particular cores to avoid this type of dynamic assignment since the software complexity will be much less than with dynamic assignment.

I apologize for this, but I'm still working on finding the root cause of the issue we've observed with the DSP OSAL timer requiring Board_init() with UART_STDIO_INIT.

Regards,
Frank

Naveen,

I worked on this late last week and today. I found that the DSP bare metal example application requires Boart_init() with BOARD_INIT_UART_STDIO for the OSAL timer to function, regardless of what the M4 is doing. More specifically, UART_osalRegisterInterrupt() must be called for the OSAL timer interrupts to fire.

The following call graph shows where UART_osalRegisterInterrupt() is called.

main()
    Board_init()
        Board_uartStdioInit()
            UART_stdioInit()
                UART_open()
                    UART_open_v1()
                        UART_osalRegisterInterrupt(&interruptRegParams,&(object->hwi)); // Osal_RegisterInterrupt()

I compared the GP Timer 5, DSP1 Interrupt Crossbar, and DSP1 INTC registers for the working and non-working cases, and the registers are the same. In the non-working case the registers appear correct and Timer 5 runs and generates interrupts, but the interrupts never appear at the DS{1 INTC Event Combiner interface. I don't have an explanation for this behavior.

I reached out internally to our OSAL / CSL expert, and he agrees this is a bug. Some code in UART_osalRegisterInterrupt() is having an unintended side effect which is causing the OSAL Timer to fire. We haven't yet identified a root cause for the bug. I'll create a bug in our tracking system so this is fixed in a future release. I should also be able to share any simple patch with you once we've root caused and fixed the issue.

Regards,
Frank

Naveen,

One possible workaround for this issue is to use a non-default "intNum" parameter for the TimerP_create() create function. For example:

//delayTimerParams.intNum = 6; // Timer5 interrupt fires on DSP, uses INTMUX to directly map Event 67 to Interrupt 6
//delayTimerParams.intNum = 7; // Timer5 interrupt fires on DSP, uses INTMUX to directly map Event 67 to Interrupt 7

Is this workaround OK for your use case? If not, how urgent is it that this issue be resolved?

Thanks and regards,
Frank

Hi Frank,

Currently I am using CSL timer libraries with out any issues, so I am thinking to continue with CSL libraries.

Regards,

Naveen.

Naveen,

Understood, thanks much.

Regards,
Frank