• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 97 subscribers
  • Views 640 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: C7x stuck into interrupt "int_exc" when access more DDR

Ming Zhong10
Intellectual 2235 points

Part Number: TDA4VM
Other Parts Discussed in Thread: SYSBIOS

Dear expert,

I want to change C7x heap memory to 0x01_0200_0000, size 1GB. When I access the data in 0x01_0200_0000, C7x will run into "int_exc" in Hwi_disp_always.s71. How to solve this?

I can view the memory in CCS memory window, and see the value using expression window. But when the code access the member of the structure, C7x will trap into this interrupt.

The map file:

MEMORY CONFIGURATION

name origin length used unused attr fill
---------------------- ------------ -------- -------- -------- ---- --------
L2RAM_C7x_1 000064800000 00078000 00078000 00000000 RWIX
L1RAM_C7x_1 000064e00000 00004000 00004000 00000000 RWIX
MSMC_C7x_1 000070020000 007c8000 007c8000 00000000 RWIX
DDR_C7x_1_IPC 0000a8000000 00100000 00000000 00100000 RWIX
DDR_C7x_1_RESOURCE_TA 0000a8100000 00000400 00000098 00000368 RWIX
DDR_C7x_1_BOOT 0000a8200000 00000400 00000080 00000380 RWIX
DDR_C7x_1_VECS 0000a8400000 00004000 00000840 000037c0 RWIX
DDR_C7x_1 0000a8404000 00bfc000 007b23dd 00449c23 RWIX
IPC_VRING_MEM 0000aa000000 02000000 02000000 00000000 RWIX
APP_LOG_MEM 0000ac000000 00040000 00040000 00000000 RWIX
TIOVX_OBJ_DESC_MEM 0000ac040000 01fa0000 00fc0000 00fe0000 RWIX
DDR_SHARED_MEM 0000ae000000 20000000 00000000 20000000 RWIX
DDR_C7X_1_SCRATCH 000100000000 02000000 02000000 00000000 RWIX
DDR_C7X_1_LOCAL_HEAP 000102000000 1c000000 1c000000 00000000 RWIX

Thanks & Best Regards!

ZM

  • 0
    TI__Intellectual 2235 points

    Background:

    I am using PSDKRA 6.2 version, I have reserved 1GB in Linux dts(start from 0x01_0000_0000).

    I am debugging a very large TIDL model, so C7x need more memory. That's why I want to move the C7x heap beyond 32bit address region.

  • 0 in reply to Ming Zhong10
    TI__Genius 10365 points

    ZM,

    On J7ES EVM the lower 2GB DDR starts from 0x0000_8000_0000 and upper 2GB of DDR is from 0x0008_8000_0000. So you will have to reserve linux memory from 0x0008_8000_0000 and not 0x0001_0000_0000, this is not DDR address.

    Now even if you map the correct DDR address there is an assembler limitation which does not allow you to have code/data span between lower 2GB and upper 2GB as its non-contiguous. So you will have to program the MMU to map 0x0008_8000_000 as 0x0001_0000_0000 and this will go through.

    But if you are using TIDL which used DRU, please note that MMU remap will work only for CPU and not DRU transfers as there is no MMU for DRU. There has to be a manual address translation in the DMAUtils API to handle this.

    This feature is requested for SDK 7.0.

    Regards,
    Shyam

  • 0 in reply to Shyam Jagannathan
    TI__Intellectual 2235 points

    Thanks Shyam. I did not realize next memory map is not contiguous.

    When I move heap to 0x08_0000_0000, the linker shows following error. It seems link failed. why there is a limitation on 36bit? and how to solve this?

    Linking /work/j7/6.2/psdk_rtos_auto_j7_06_02_00_21/vision_apps/out/J7/C71/SYSBIOS/debug/vx_app_tirtos_linux_c7x_1.out
    "/work/j7/6.2/psdk_rtos_auto_j7_06_02_00_21/vision_apps/apps/basic_demos/app_tirtos/common/app_init.c", line 753: warning:
    relocation from function "appInit" to symbol "g_ddr_shared_mem" overflowed;
    the 36-bit relocated address 0x7576848c0 is too large to encode in the
    32-bit signed PC-Relative field (type = 'R_C7X_PCR_OFFSET_ADDKPC_HI27' (33),
    file =
    "/work/j7/6.2/psdk_rtos_auto_j7_06_02_00_21/vision_apps/out/J7/C71/SYSBIOS/d
    ebug/app_tirtos_common_c7x_1.lib<app_init.obj>", offset = 0x0000000000d0,
    section = ".text")
    "/work/j7/6.2/psdk_rtos_auto_j7_06_02_00_21/vision_apps/apps/basic_demos/app_tirtos/common/app_init.c", line 753: warning:
    relocation from function "appInit" to symbol "g_ddr_scratch_mem" overflowed;
    the 36-bit relocated address 0x777684700 is too large to encode in the
    32-bit signed PC-Relative field (type = 'R_C7X_PCR_OFFSET_ADDKPC_HI27' (33),
    file =
    "/work/j7/6.2/psdk_rtos_auto_j7_06_02_00_21/vision_apps/out/J7/C71/SYSBIOS/d
    ebug/app_tirtos_common_c7x_1.lib<app_init.obj>", offset = 0x000000000278,
    section = ".text")
    warning: output file
    "/work/j7/6.2/psdk_rtos_auto_j7_06_02_00_21/vision_apps/out/J7/C71/SYSBIOS/d
    ebug/vx_app_tirtos_linux_c7x_1.out" cannot be loaded and run on a target
    system

  • 0 in reply to Ming Zhong10
    TI__Genius 10365 points

    ZM,

    As I mentioned, there is an assembler restriction which does not allow code/data to be beyond +/- 2GB. Because of this we cannot use both lower 2BG and upper 2GB as the addresses are far apart. One way to resolve this is use MMU to make it contiguous and mark the upper 2GB sections as NO_LOAD, keep mostly scratch or heap buffers there. This will pass the assembler stage but the MMU works only for C7x CPU and not DRU. As TIDL uses DRU extensively your DMA transfers will fail. There is a request put perform manual address translation in DMAUtils but this is targeted for SDK 7.0 release.

    Regards,
    Shyam

  • 0 in reply to Shyam Jagannathan
    TI__Intellectual 2235 points

    Thanks! I am clear.

    I will find other ways to debug.