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: QNX C66 task priority: remote service rx tasks vs tivx target kernel tasks

Part Number: TDA4VM

Hi: 

  The sdk "ti-processor-sdk-rtos-j721e-evm-07_03_00_07" and APP "vision_apps" are depolyed on TDA4VM with QNX rtos.

  On C66 there are two tasks registed, one is "tivxRegisterImgProcTargetC66Kernels()" which is provided by sdk with default settings, the other is a user-defined kernels and triggered by remote service. They worked well when separately scheduled.  

   When scheduled at the same time, I found that the task priority of  remote service is higher than tivx kernels so that it will interrupt tivx kernels. I want they are of the same priority and run on C66 serially. Then I try the following :

  1  In " ti-processor-sdk-rtos-j721e-evm-07_03_00_07\vision_apps\kernels\img_proc\c66\vx_image_preprocessing_target.c" I use "#define DISABLE_INTERRUPTS_DURING_PROCESS" and the "HwiP_disable()" is called, but it does not work. The tivx kernel is still interrupted by remote service on C66.

  2 In "ti-processor-sdk-rtos-j721e-evm-07_03_00_07\vision_apps\utils\remote_service\src\app_remote_service.c" I changed the task priority in function "appRemoteServiceInit(app_remote_service_init_prms_t *prm)" around line "455".   The default value of APP_REMOTE_SERVICE_RX_TASK_PRI is 10.   I tried twice,  once changed to 15, another changed to 8. It also does not work. The tivx kernel is still interrupted by remote service  on C66.

   So my question is that:

  If I write a user-defined kernels on C66/C71 and triggered by  remote service, how to change the task priority on DSP RX tasks?

  What is the default priority of tivx kernels? How to change it?

  Is there a safe method to disable all interrupts on DSP for a while?

 Thx a lot!

  Best regards!

  • Hi:

       So need I provide more information for this issue?

       Thx!

  • Hi,

    May I know if your custom kernel is running on target DSP1 or DSP2? If yes, then the default priority for both is 8. You could find this in ${PSDKRA}/tiovx/source/platform/psdk_j7/rtos/tivx_target_config_c66.c

    If I write a user-defined kernels on C66/C71 and triggered by  remote service

    Could you brief me what do you mean by the above? 

    Could you also brief me what is your usecase when the remote service is triggered? Do you want the existing kernel in C66x to complete and then proceed with the user defined kernel's process function? or remote service should not interrupt the C66x kernel at all?

    Regards,

    Nikhil

  • Hi Nikhil:

    Thx for reply!!

    Firstly, I also find the default task priority of tivx kernel is 8. But I am not sure that if the highest priority is 15 or 0?

    Then, My user defined kernels on C66 is very simple, it is the same as the utils sample.
    I register the remote service handler on C66. So the MPU will trigger the C66 by remote service with a user-defined string "xxxx".
    It works well when I only run this kernel separately.


    Now In MPU there are 2 threads. One calls the tivx kernels on C66_1 and the other calls the remote service kernels on C66_1 meanwhile.
    (c66_2 is not availabld yet)
    The requirement is that I want the priority of these two kind of kernels are the same so that they works on C66_1 serially.
    (no one can interrupt the other. If One is not finished, the other will in message queue and wait)

    The default task priority of remote service RX may be 10 ? I am not sure.
    I just find the code like this " #define APP_REMOTE_SERVICE_RX_TASK_PRI (10u) " in "app_remote_service.c"
    And I modified it to 8u, but it does not work. The remote service hander still interrupt the tivx kernels.

    So I dont know where to modify the remote service rx task priority on C66 now . (QNX rtos)

    Thx a lot!

    Best regards!

  • Hi:

      Is there anything  I can do for this issue?

      Thx a lot!

  • Hi,

    Could you please try to increase the priority of C66 kernel task "TIVX_TARGET_DEFAULT_TASK_PRIORITY" to 11 from 8 in ${PSDKRA}/tiovx/source/platform/psdk_j7/rtos/tivx_target_config_c66.c and rebuild the sdk?

    Please let me know if this still interrupts the flow.

    Regards,

    Nikhil

  • Hi Nikhil:

      Thx for reply!!

      Unfortunetely we cannot modify the tiovx, pdk, and so on ...  They are provided by the integrator. 

      We can only work on vision_apps.

      On the other side, we can not set the tivx target task priority higher than remote service, since the remote service should not be interrputed by tivx also. They use the same L2 memory on dsp.

      So is there any suggestions on remote service?

      By the way, I have another question that, if the interrupt happen, what does the OS do to protect the memory and registers on C66? Currently in our senario, the low priority task allocate the L2 memory. Then high priority tasks comes, the high priority task will allocate the L2 memory and return fail, since the L2 memory is not freed by the low priority tasks. 

      Thx a lot!

       Best regards!

  • Hi,

    On the other side, we can not set the tivx target task priority higher than remote service, since the remote service should not be interrputed by tivx also. They use the same L2 memory on dsp

    If you keep the same priority for remote service and the target C66, then this should work, but there shouldn't be any semaphore_pend() in the kernel task.

    If there is a wait happening for the semaphore, then it would automatically switch to other Task. Hence this should be avoided.

    By the way, I have another question that, if the interrupt happen, what does the OS do to protect the memory and registers on C66? Currently in our senario, the low priority task allocate the L2 memory. Then high priority tasks comes, the high priority task will allocate the L2 memory and return fail, since the L2 memory is not freed by the low priority tasks. 

    In the SDK, when there is a task switch, the context is saved and restored, but each stack should have individual stacks. Freeing up of these by the low priority task for the high priority to use should be done at your end using some hookup functions as this would be specific to your usecase.

    Regards,

    Nikhil