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.
Hi team,
Customer is dong the modify on signal chain. And the L2 RAM is not enough for code. Can DSP code put on L3 and run?
How to modify the CMD file?
The error information are listed below:
<Linking> "../c674x_linker.cmd", line 87: error #10099-D: program will not fit into available memory. placement with alignment fails for section ".fardata" size 0x139f . Available memory ranges: L2SRAM_UMAP0 size: 0x20000 unused: 0x11 max hole: 0x7 L2SRAM_UMAP1 size: 0x20000 unused: 0x0 max hole: 0x0 "../c674x_linker.cmd", line 89: error #10099-D: program will not fit into available memory. placement with alignment fails for section ".switch" size 0x20a . Available memory ranges: L2SRAM_UMAP0 size: 0x20000 unused: 0x11 max hole: 0x7 L2SRAM_UMAP1 size: 0x20000 unused: 0x0 max hole: 0x0 "../c674x_linker.cmd", line 96: error #10099-D: program will not fit into available memory. run placement with alignment fails for section ".stack" size 0x418 . Available memory ranges: L2SRAM_UMAP0 size: 0x20000 unused: 0xd max hole: 0x7 L2SRAM_UMAP1 size: 0x20000 unused: 0x0 max hole: 0x0 "../c674x_linker.cmd", line 90: error #10099-D: program will not fit into available memory. run placement with alignment fails for section ".cio" size 0x127 . Available memory ranges: L2SRAM_UMAP0 size: 0x20000 unused: 0xd max hole: 0x7 L2SRAM_UMAP1 size: 0x20000 unused: 0x0 max hole: 0x0 "../c674x_linker.cmd", line 95: error #10099-D: program will not fit into available memory. placement with alignment fails for section ".neardata" size 0x32 . Available memory ranges: L2SRAM_UMAP0 size: 0x20000 unused: 0xd max hole: 0x7 L2SRAM_UMAP1 size: 0x20000 unused: 0x0 max hole: 0x0 warning #10370-D: Possible codesize or performance degradation. Section ".text:MmwDemo_interFrameProcessing:dss_data_path.oe674" has calls to rts routines, but rts is placed out of range from call site at 0xe01b20, or in a different section. To optimize codesize, either 1) place rts closer to call site, or 2) place rts in same section, or 3) compile with --disable_push_pop. warning #10370-D: Possible codesize or performance degradation. Section ".text:MmwDemo_interFrameProcessing:dss_data_path.oe674" has calls to rts routines, but rts is placed out of range from call site at 0xe03118, or in a different section. To optimize codesize, either 1) place rts closer to call site, or 2) place rts in same section, or 3) compile with --disable_push_pop. warning #10370-D: Possible codesize or performance degradation. Section ".text:SOC_init:libsoc_xwr16xx.ae674<soc.oe674>" has calls to rts routines, but rts is placed out of range from call site at 0x20007d04, or in a different section. To optimize codesize, either 1) place rts closer to call site, or 2) place rts in same section, or 3) compile with --disable_push_pop. warning #10370-D: Possible codesize or performance degradation. Section ".text:SOC_init:libsoc_xwr16xx.ae674<soc.oe674>" has calls to rts routines, but rts is placed out of range from call site at 0x20007c00, or in a different section. To optimize codesize, either 1) place rts closer to call site, or 2) place rts in same section, or 3) compile with --disable_push_pop. warning #10281-D: Section ".bss" requires a STATIC_BASE relative relocation, but is located at 0x0081cf7c, which is probably out of range of the STATIC_BASE. STATIC_BASE is located at 0x00000000. Might be required to correct placement of ".bss" so it lies within 0x8000 of the STATIC_BASE. "../dss_mmw_linker.cmd", line 59: error #10099-D: program will not fit into available memory. placement with alignment fails for section ".ovly" size 0x10 . Available memory ranges: L2SRAM_UMAP0 size: 0x20000 unused: 0x7 max hole: 0x7 L2SRAM_UMAP1 size: 0x20000 unused: 0x0 max hole: 0x0 warning #10281-D: Section ".bss" requires a STATIC_BASE relative relocation, but is located at 0x0081cf7c, which is probably out of range of the STATIC_BASE. STATIC_BASE is located at 0x00000000. Might be required to correct placement of ".bss" so it lies within 0x8000 of the STATIC_BASE. error #10010: errors encountered during linking; "xwr16xx_mmw_dss.xe674" not built >> Compilation failure
Regards,
Wesley
Hi team,
I had tried to modify c674x_linker.cmd file
1. modify the L1P_CACHE_SIZE
#define L1P_CACHE_SIZE (16*1024)
to
#define L1P_CACHE_SIZE (4*1024)
But it doesn't work. the error is same.
2. allocate a L3RAM for some data like below, the compile is succeed, but after i load program into device, Load CFG through GUI, nothing happen, the program halt. And CCS didn't report any error. Could you please point out which section can be placed in L3.
Thanks
/* * Copyright (c) 2016, Texas Instruments Incorporated * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * * Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * * Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * * Neither the name of Texas Instruments Incorporated nor the names of * its contributors may be used to endorse or promote products derived * from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #define L1P_CACHE_SIZE (16*1024) #define L1D_CACHE_SIZE (16*1024) MEMORY { PAGE 0: #if (L1P_CACHE_SIZE < 0x8000) L1PSRAM: o = 0x00E00000, l = (0x00008000 - L1P_CACHE_SIZE) #endif #if (L1D_CACHE_SIZE < 0x8000) L1DSRAM: o = 0x00F00000, l = (0x00008000 - L1D_CACHE_SIZE) #endif L2SRAM_UMAP1: o = 0x007E0000, l = 0x00020000 L2SRAM_UMAP0: o = 0x00800000, l = 0x00020000 //L3SRAM: o = 0x20000000, l = MMWAVE_L3RAM_SIZE L3SRAM: o = 0x20004000, l = MMWAVE_L3RAM_SIZE - 0x00004000 L3_RAM_CONST: o = 0x20000000, l = 0x00004000 HSRAM: o = 0x21080000, l = 0x8000 /* PAGEs 1 and onwards are for overlay purposes for memory optimization. Some examples: 1. Overlay one-time only text with uninitialized data. 2. Overlay L1PSRAM data path processing fast code and use copy tables to page in (before entering data path) and out of L1PSRAM (when entering sleep/low power). */ PAGE 1: L3SRAM: o = 0x20000000, l = MMWAVE_L3RAM_SIZE // L3SRAM: o = 0x20000000, l = MMWAVE_L3RAM_SIZE - 0x00004000 } /* Set L1D, L1P and L2 Cache Sizes */ ti_sysbios_family_c64p_Cache_l1dSize = L1D_CACHE_SIZE; ti_sysbios_family_c64p_Cache_l1pSize = L1P_CACHE_SIZE; ti_sysbios_family_c64p_Cache_l2Size = 0; SECTIONS { /* hard addresses forces vecs to be allocated there */ .vecs: {. = align(32); } > 0x007E0000 /* Allocate data preferentially in one UMAP and code (.text) in another, this can improve performance due to simultaneous misses from L1P and L1D caches to L2 SRAM, for more information see C674 Megamodule User Guide section "Level 2 Memory Architecture". The linker notation "X >> Y | Z" indicates section X is first allocated in Y and allowed to overflow into Z and can be split from Y to Z. The linker notation "X > Y | Z" indicates section X is first allocated in Y and allowed to overflow into Z and cannot be split from Y to Z. Some sections like bss are not allowed to be split so > notation is used for them */ .fardata: {} >> L2SRAM_UMAP0 | L2SRAM_UMAP1 .const: {} >> L3_RAM_CONST .switch: {} >> L2SRAM_UMAP0 | L2SRAM_UMAP1 .cio: {} >> L2SRAM_UMAP0 | L2SRAM_UMAP1 .data: {} >> L2SRAM_UMAP0 | L2SRAM_UMAP1 .rodata: {} > L2SRAM_UMAP0 | L2SRAM_UMAP1 .bss: {} > L2SRAM_UMAP0 | L2SRAM_UMAP1 .neardata: {} > L2SRAM_UMAP0 | L2SRAM_UMAP1 .stack: {} > L2SRAM_UMAP0 | L2SRAM_UMAP1 .cinit: {} > L2SRAM_UMAP0 | L2SRAM_UMAP1 .far: {} > L2SRAM_UMAP0 | L2SRAM_UMAP1 .text: {} >> L2SRAM_UMAP1 | L2SRAM_UMAP0 }
Hi Wesley,
Please look at the following thread which addresses the same question in context of IWR1443. As defined in this thread, program memory can be increased (at the expense of Radar cube memory) in fixed size increments i.e. bank size and this information is sent to the image generation utility in the SHMEM alloc parameter. For IWR1642, the default and alternate shared memory allocations are defined under mmwave_sdk_xwr16xx.mak using the MMWAVE_SDK_SHMEM_ALLOC parameter.
CCS/IWR1443BOOST: Verification failed: Internal error while writing 0x0001F550
Based on your device, you need to change this parameter in mmwave_sdk_xwr16xx.mak and the SDK will automatically use the correct memory allocations in the linker command file.
Thanks
-Nitin