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.

TDA4VM: How to avoid sci failed while booting by ospi

Part Number: TDA4VM

Hello TI Teams:

          I tried to use OSPI to decrease the startup time , 

         I used TI's demo("sbl_cust_img" and “can_boot_app_mcu_rtos”) and i tried to modified the demo(can_boot_app_mcu_rtos), so that it could jump to my APP and start the QNX 

        The startup process is:(sbl_cust_img -> can_boot_app_mcu_rtos -> start My APP & QNX). 

        It could jump to my APP correctly and start the QNX, But Sometimes it will failed becasue of sci server failed. By the way , i have sci server in My App. 

The logs below:

ERROR:   GTC_CNTFID0 is 0! Assuming 200000000 Hz. Fix Bootloader
MMU: 16-bit ASID 44-bit PA TCR_EL1=b5183519
cpu0: MPIDR=80000000
cpu0: MIDR=411fd080 Cortex-A72 r1p0
cpu0: CWG=4 ERG=4 Dminline=4 Iminline=4 PIPT
cpu0: CLIDR=a200023 LoUU=1 LoC=2 LoUIS=1
cpu0: L1 Icache 48K linesz=64 set/way=256/3
cpu0: L1 Dcache 32K linesz=64 set/way=256/2
cpu0: L2 Unified 1024K linesz=64 set/way=1024/16
ti_sci_recv_message, unable to receive message
init_gpu: Set GPU0 device state failed!
ti_sci_recv_message, unable to receive message
init_gpu: Set GPU1 device state failed!
Display set to R5
ti_sci_recv_message, unable to receive message
init_ospi: Set OSPI0 RCLK clock parent failed!
ti_sci_recv_message, unable to receive message
init_usb_host: HOST 0, failed! 69
ti_sci_recv_message, unable to receive message
init_usb_host: HOST 1, failed! 69
Loading IFS...decompressing...done
ERROR:   Timeout waiting for thread SP_RESPONSE to fill
ERROR:   Thread SP_RESPONSE verification failed (-60)
ERROR:   Message receive failed (-60)
ERROR:   Failed to get response (-60)
ERROR:   Transfer send failed (-60)
ERROR:   Request to start core failed: -60

       My questions:

1. I think the root cause is there has a time window that hasn't sci server (From can_boot_app_mcu_rtos jump to My APP ). Is it right?, If not, What's the reason?

2. Could you please provide some Offical Solution to avoid this problem?

  • Hello,

    Yes, it does sound like this is the issue. If you allow your app to only run the SCIServer and disable the rest of the app, do you still see the issue? This can prove that the issue is with the frequency the SCIServer is available. I will check and come back to you on the frequency of the SciServer avalibility.

    Regards,

    Erick

  • Hello,

    One more thing to note is the priority of the server should be high, if not the highest. Please see this comment from the sciserver_tirtos.h:

     *         NOTE: If this function is called form a Task Context
     *         (i.e, not from main / after starting the Schedular),
     *         the callee Task should be of priority higher than  
     *         max of passed init param(pPrms) Task priorities
     *         i.e Sciserver_TirtosCfgPrms_t->taskPriority[x]

    Please let me know if this helps.

    Regards,

    Erick

  • Hello Erick

            Thanks for your reply.

            yes , the sci server is the highest task in my app. but it still has a window time that hasn't sci server(T1) , The time  start from can_boot_app_mcu_rtos jump to My APP(T2), and  from My App init hardware to  start sci server task(T3), T1 = T2 + T3.

            Is there has some way to avoid this problem?

  • one more question, if the can_boot_app_mcu_rtos had start d sci server, should i need to start sci server again in My App program? because I am not sure whether the sci server will still exist while it jumping to My App

  • Hi June,

    Can you clarify which core you want your app to run on? It will only need to run the SciServer if you are running on mcu1_0 (the first core of the MCU R5Fs).

    If "My App" does not run on mcu1_0, then no, you will not need to start sci_server again, it would be loaded and keep running on mcu1_0.

    If "My App" runs on mcu1_0, then yes, you will need to continue to handle sci_server within your app context.

    To clarify, without "My App" running, you don't see any issue?

    Regards,

    Erick

  • Hello Erick:

    Can you clarify which core you want your app to run on? 

    -> "My App" runs on mcu1_0,

    To clarify, without "My App" running, you don't see any issue?

    -> without "My App" running, i will not  see any issue. 

    Actually, i have try to workround this issue:

    1. i add a delay time in the other Core(Mcu2_0, A72) to make sure "My App" has enough time to running sci server, so that  the sci request could be responsed by "My App". but it needs to add a delay time in all other core except MCU1_0, it's oo complicated. and i am not sure how much time need  delay. The delay time maybe depends on the computational complexity in the other cores.

     So i think it is not a good solution. Is there has some way to avoid this problem?

  • June,

    How quickly do you start the SciServer in your application? As you can see from our Can Profiling App, we don't see this issue, and it is initialized very quickly, almost immediately after the OS_init() call.

    122 int main(void)
    123 {
    124 TaskP_Handle task;
    125 TaskP_Params taskParams;
    126 sint32 ret = CSL_PASS;
    127
    128 OS_init();
    129
    130 #ifdef UART_ENABLED
    131 AppUtils_Init();
    132 #endif
    133
    134 /* Initialize SCI Client Server */
    135 ret = SetupSciServer();
    136 if(ret != CSL_PASS)
    137 {
    138 OS_stop();
    139 }

    Regards,

    Erick

  • Hello Erick

    Thanks for your reply.

    The SciServer start from McalDriver_Init() call to OsTask_SciServer_Task() call spend 7ms.

    Actully,The SciServer start from the OS_init() call to McalDriver_Init() call take a while.

    So think it took 20+ ms in total.

    I want you to help us analyze.


    Regards.

  • Hi June,

    For the A72 SciClient commands to function, the SciServer must be running on the MCU1_0.

    On the A72 side

    • If the timing of SciServer availability is close to A72 SciClient commands running, a polling mechanism could be put in place, where the A72 initialization include logic, which polls the SciServer to successfully respond, before continuing the boot flow.
    • Another alternative would be to move the A72 SciClient commands as late as possible in the A72 initialization sequence.

    On the MCU1_0 side:

    • Recommendation is to make the SciServer available as early as possible in the MCU1_0 boot flow.
    • The total time taken to to SciServer being launched on MCU1_0, can be compared to the total time taken to reach the first A72 SciClient command.
    • Determine how big the window of failure is, this will assist in your design decisions.

    Other alternatives

    • The SciServer must be run on MCU1_0, but other boot flow functionality such as loading / releasing Main domain cores, could be run from a different core.  By offloading some of this functionaliy from MCU1_0, it may allow the SciServer to be available earlier in the overall boot flow.

    Regards,

    kb