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: Question about ti-img-encode-decode

Part Number: TDA4VM

Hi TI experts,

     When I was executing the application, the following problems occurred,

     test_app is  --> ./vx_app_conformance.out --filter=tivxHwaVideoEncoder.SingleStreamProcessing

     The application is stuck,The printing information is as follows,

     

root@j7-evm:/opt/vision_apps# ./vx_app_conformance.out --filter=tivxHwaVideoEncoder.SingleStreamProcessing
APP: Init ... !!!
MEM: Init ... !!!
MEM: Initialized DMA HEAP (fd=4) !!!
MEM: Init ... Done !!!
[ZHC ADDED]APP:ENABLE_IPC_MCU2_0 Init ... !!!
IPC: Init ... !!!
IPC: Init ... Done !!!
REMOTE_SERVICE: SUCCESS: register handler[0][8] for service [com.ti.module_ctrl]
REMOTE_SERVICE: Init ... !!!
REMOTE_SERVICE: Init ... Done !!!
REMOTE_SERVICE: SUCCESS: register handler[0][8] for service [com.ti.perf_stats]
APP: Init ... Done !!!
  5596.669255 s:  VX_ZONE_INIT:Enabled
  5596.669278 s:  VX_ZONE_ERROR:Enabled
  5596.669285 s:  VX_ZONE_WARNING:Enabled
  5596.669886 s:  VX_ZONE_INIT:[tivxInit:71] Initialization Done !!!
  5596.670076 s:  VX_ZONE_INIT:[tivxHostInit:56] Initialization Done for HOST !!!
VxTests version: 1.1-20170301
VCS version: unknown
Build config: Release

[ ======== ] Total 22704 tests from 151 test cases
Use test filter: tivxHwaVideoEncoder.SingleStreamProcessing

Use global OpenVX context: FALSE


[ -------- ] tests from tivxHwaVideoEncoder
[ RUN 0001 ] tivxHwaVideoEncoder.SingleStreamProcessing ...
[MCU2_0]   5599.276205 s: TIMEOUT: topazdd_wait_on_sync timed out waiting for writeback 0x05a80000.

     I try to analyze the source code(SDK 7.00),The function osa_irqreturn_t topazdd_isr(void * inst_data) was found to have entered the branch of “ Page fault ”,Then all interrupts were disabled.

     Reg  TOPAZHP_TOP_CR_MULTICORE_INT_STAT  is 0x80000011

     

     Reg  TOPAZHP_TOP_CR_MMU_STATUS                 is 0x00000001

    

     So please help me to locate why this problem occurs?

     We also adjusted the memory layout before

                                         modified                                                                                                                                            Original file

      

      

       

        Do the above operations cause the above problems? If so, how will we solve it?

       

       Looking for your reply!

       Best regards!

       

  • Hi,

    Please ignore the below error. It is harmless.

    [MCU2_0]   5599.276205 s: TIMEOUT: topazdd_wait_on_sync timed out waiting for writeback 0x05a80000.

    Did you change anything in the memory map? or are you using default released memory map? 

    The codec requires additional memory on the core on which it is running, so can you please keep the memory map same on this core?

    Regards,

    Brijesh

  • HI Brijesh,

         Thanks for your reply. The part I changed in gen_linker_mem_map.py has been marked in the above picture.

    in  gen_linker_mem_map.py

    #
    # DDR, MSMC base and size
    #

    ddr_mem_addr = 0xa0000000;
    ddr_mem_size = 1*GB + 448*MB; # Last 64MB is used by Linux
    ddr_buf_mem_size = 512*MB;                                      --------------------------------------------->   change to 304*MB;
    msmc_mem_addr = 0x70000000;

    # Note, C6x_2 IPC region is just before C6x_1 resource table to allow to set MAR bit for C6x_2 IPC region to non-cached
    c66x_2_ddr_ipc_addr = mcu3_1_ddr_addr + mcu3_1_ddr_size;
    c66x_1_ddr_resource_table_addr = c66x_2_ddr_ipc_addr + linux_ddr_ipc_size;
    c66x_1_ddr_boot_addr = c66x_1_ddr_resource_table_addr + 1*MB;
    c66x_1_ddr_boot_size = 1*KB;
    c66x_1_ddr_addr = c66x_1_ddr_boot_addr + c66x_1_ddr_boot_size;
    c66x_1_ddr_size = 16*MB - (c66x_1_ddr_addr-c66x_2_ddr_ipc_addr);   ---------------------->  change to 26*MB;

    # Note, C6x_1 IPC region is just before C6x_2 resource table to allow to set MAR bit for C6x_1 IPC region to non-cached
    c66x_1_ddr_ipc_addr = c66x_1_ddr_addr + c66x_1_ddr_size;
    c66x_2_ddr_resource_table_addr = c66x_1_ddr_ipc_addr + linux_ddr_ipc_size;
    c66x_2_ddr_boot_addr = c66x_2_ddr_resource_table_addr + 1*MB;
    c66x_2_ddr_boot_size = 1*KB;
    c66x_2_ddr_addr = c66x_2_ddr_boot_addr + c66x_2_ddr_boot_size;
    c66x_2_ddr_size = 16*MB - (c66x_2_ddr_addr-c66x_1_ddr_ipc_addr); -------------------------> change to 26*MB;

    c7x_1_ddr_ipc_addr = c66x_2_ddr_addr + c66x_2_ddr_size;
    c7x_1_ddr_resource_table_addr = c7x_1_ddr_ipc_addr + linux_ddr_ipc_size;
    c7x_1_ddr_boot_addr = c7x_1_ddr_resource_table_addr + 1*MB;
    c7x_1_ddr_boot_size = 1*KB;
    c7x_1_ddr_vecs_addr = c7x_1_ddr_resource_table_addr + 3*MB;
    c7x_1_ddr_vecs_size = 16*KB;
    c7x_1_ddr_secure_vecs_addr = c7x_1_ddr_resource_table_addr + 5*MB;
    c7x_1_ddr_secure_vecs_size = 16*KB;
    c7x_1_ddr_addr = c7x_1_ddr_secure_vecs_addr + c7x_1_ddr_secure_vecs_size;
    c7x_1_ddr_size = 16*MB - (c7x_1_ddr_addr-c7x_1_ddr_ipc_addr);    --------------------------->  change to 24*MB;

    mcu1_0_ddr_local_heap_addr = mcu2_0_ddr_non_cache_addr + mcu2_0_ddr_non_cache_size;
    mcu1_0_ddr_local_heap_size = 4*MB;      ---------------------------------------------------------------> change to 16*MB;
    mcu1_1_ddr_local_heap_addr = mcu1_0_ddr_local_heap_addr + mcu1_0_ddr_local_heap_size;
    mcu1_1_ddr_local_heap_size = 4*MB;      ---------------------------------------------------------------> change to 16*MB;
    mcu2_0_ddr_local_heap_addr = mcu1_1_ddr_local_heap_addr + mcu1_1_ddr_local_heap_size;
    mcu2_0_ddr_local_heap_size = 16*MB;   
    mcu2_1_ddr_local_heap_addr = mcu2_0_ddr_local_heap_addr + mcu2_0_ddr_local_heap_size;
    mcu2_1_ddr_local_heap_size = 4*MB;      ---------------------------------------------------------------> change to 64*MB;
    mcu3_0_ddr_local_heap_addr = mcu2_1_ddr_local_heap_addr + mcu2_1_ddr_local_heap_size;
    mcu3_0_ddr_local_heap_size = 2*MB;      ---------------------------------------------------------------> change to 64*MB;
    mcu3_1_ddr_local_heap_addr = mcu3_0_ddr_local_heap_addr + mcu3_0_ddr_local_heap_size;
    mcu3_1_ddr_local_heap_size = 2*MB;      ---------------------------------------------------------------> change to 64*MB;

    Then I  run the  gen_linker_mem_map.py. The released memory map has been changed.

          And question is that how can I keep the memory map same on this core?

          I didn't find a place to configure the codec memory map,  please help me find it ? 

     Best regards!

         

  • Hi,

    Could you search in the memory map? There is a local heap on mcu2_1 (or non-cached scratch memory), which is set to higher size for codec?

    Also if you revert these changes, does the codec work fine? Just want to see if the issue is due to memory map changes?

    Regards,

    Brijesh

  • HI Brijesh,

         In addition to changing gen_linker_mem_map.py, we also changed k3-j721e-som-p0.dtsi. I will recover these two files then try codec again.

         Besides, I am sorry that I can't understand what you mean about search in the memory map and a local heap on mcu2_1 (or non-cached scratch memory) ?

         In fact, codec runs on core mcu2_0. video_codec_decoder_tirtos.lib is not dynamically connected  by vx_app_tirtos_linux_mcu2_1.out ,but  vx_app_tirtos_linux_mcu2_0.out. so did you mean we should find  a local heap on mcu2_0 (or non-cached scratch memory)?

         How can I search the memory map used for codec ? I didn't find any tips? and which file should I search? vx_app_tirtos_linux_mcu2_0.out.map?app_mem_map.h?or anything else?

         This is difficult for me. Please explain it in detail,thanks a lot!

         Best Regards!

       

  • Hi Zhang huicheng,

    I guess you are using old release, SDK7.0.. Because in newer release, codec runs on mcu2_1. 

    Yes, on the SDK7.0 release, please search for scratch, non-cached, heap memory for mcu2_0 in your memory map. You could look for these sections in ti-processor-sdk-rtos-j721e-evm-07_03_00_07/vision_apps/apps/basic_demos/app_tirtos/tirtos_linux/system_memory_map.html file..

    Regards,

    Brijesh

  • HI Brijesh,

         I forgot to modify r5_mpu.xs. The problem is solved.

         Thanks a lot!

    Best Regards!

         

  • Thank you Zheng, closing this thread.