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.

CCS/66AK2H06: CCS load error with C66x codes

Part Number: 66AK2H06

Tool/software: Code Composer Studio

Hi,

My customer using 66AK2H06 reported an error with CCS while they are debugging C66x codes on EVMK2H.
(all file extension are changed to *.txt)

Please see below CCS console log.
When target is connected, GEL file runs correctly and finish at line#47.
Then customer tried to load program, and Error -1176 were generated.
It seems the code are load at address 0x0 where is not memory mapped.

C66xx_0: GEL Output: 
Connecting Target...
C66xx_0: GEL Output: TCI6638K2K GEL file Ver is 1.70000005 
C66xx_0: GEL Output: Detected PLL bypass enabled: SECCTL[BYPASS] = 0x00800000
C66xx_0: GEL Output: (2a) MAINPLLCTL1 = 0x00000040
C66xx_0: GEL Output: (2b) PLLCTL = 0x00000048
C66xx_0: GEL Output: (2c) PLLCTL = 0x00000048
C66xx_0: GEL Output: (2d) Delay...
C66xx_0: GEL Output: (2e) SECCTL = 0x00810000
C66xx_0: GEL Output: (2f) PLLCTL = 0x0000004A
C66xx_0: GEL Output: (2g) Delay...
C66xx_0: GEL Output: (2h) PLLCTL = 0x00000048
C66xx_0: GEL Output: (4)PLLM[PLLM] = 0x0000000F
C66xx_0: GEL Output: MAINPLLCTL0 = 0x05000000
C66xx_0: GEL Output: (5) MAINPLLCTL0 = 0x07000000
C66xx_0: GEL Output: (5) MAINPLLCTL1 = 0x00000040
C66xx_0: GEL Output: (6) MAINPLLCTL0 = 0x07000000
C66xx_0: GEL Output: (7) SECCTL = 0x00890000
C66xx_0: GEL Output: (8a) Delay...
C66xx_0: GEL Output: PLL1_DIV3 = 0x00008002
C66xx_0: GEL Output: PLL1_DIV4 = 0x00008004
C66xx_0: GEL Output: PLL1_DIV7 = 0x00000000
C66xx_0: GEL Output: (8d/e) Delay...
C66xx_0: GEL Output: (10) Delay...
C66xx_0: GEL Output: (12) Delay...
C66xx_0: GEL Output: (13) SECCTL = 0x00090000
C66xx_0: GEL Output: (Delay...
C66xx_0: GEL Output: (Delay...
C66xx_0: GEL Output: (14) PLLCTL = 0x00000041
C66xx_0: GEL Output: PLL has been configured (CLKIN * PLLM / PLLD / PLLOD = PLLOUT):
C66xx_0: GEL Output: PLL has been configured (122.879997 MHz * 16 / 1 / 2 = 983.039978 MHz)
C66xx_0: GEL Output:  DISABLESTAT ---> 0x000007FF 
C66xx_0: GEL Output: Power on all PSC modules and DSP domains... 
C66xx_0: GEL Output: Power on all PSC modules and DSP domains... Done.
C66xx_0: GEL Output: WARNING: SYSCLK is the input to the PA PLL.
C66xx_0: GEL Output: Completed PA PLL Setup
C66xx_0: GEL Output: PAPLLCTL0 - before: 0x0x098804C0	 after: 0x0x09080500
C66xx_0: GEL Output: PAPLLCTL1 - before: 0x0x00000040	 after: 0x0x00002040
C66xx_0: GEL Output: DDR begin
C66xx_0: GEL Output: XMC setup complete.
C66xx_0: GEL Output: DDR3 PLL (PLL2) Setup ... 
C66xx_0: GEL Output: DDR3 PLL Setup complete, DDR3A clock now running at 666 MHz.
C66xx_0: GEL Output: DDR3A initialization complete 
C66xx_0: GEL Output: DDR3 PLL Setup ... 
C66xx_0: GEL Output: DDR3 PLL Setup complete, DDR3B clock now running at 800MHz.
C66xx_0: GEL Output: DDR3B initialization complete 
C66xx_0: GEL Output: DDR done
C66xx_0: Trouble Writing Register PC: (Error -1176 @ 0x0) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.903.2) 
C66xx_0: Symbol Manager: the object file contains multiple sets of debug information; only the first set will be used.
C66xx_0: Trouble Setting Breakpoint with the Action "Terminate Program Execution" at 0x86800: (Error -1176 @ 0x8681C) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.903.2) 
C66xx_0: Breakpoint Manager: Retrying with a AET breakpoint
C66xx_0: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x85bc0: (Error -1176 @ 0x85BDC) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.903.2) 
C66xx_0: Breakpoint Manager: Retrying with a AET breakpoint

Customer checked *.map files (see below) and found;
- According to SECTION ALLOCATION MAP, nothing is mapped at 0x0, 0x8681C or 0x85BDC.
- GLOBAL SYMBOLS(line#3181) shows many symbols are mapped at 0x0 or other region outside of MEMORY CONFIGURATION.
memory map.txt


The linker command file used by customer is below.
/****************************************************************************/
/*  66AK2Gxx_C66.cmd                                                        */
/*  Copyright (c) 2016  Texas Instruments Incorporated                      */
/*  Author: Rafael de Souza                                                 */
/*                                                                          */
/*    Description: This file is a sample linker command file that can be    */
/*                 used for linking programs built with the C compiler and  */
/*                 running the resulting .out file on the C66x DSP core of  */
/*                 a 66AK2Gxx device.                                       */
/*                 Use it as a guideline.  You will want to                 */
/*                 change the memory layout to match your specific          */
/*                 target system.  You may want to change the allocation    */
/*                 scheme according to the size of your program.            */
/*                                                                          */
/****************************************************************************/
-c
-stack 0x4000

MEMORY
{
    /* ---- DSP 0: 0x0C200000 - 0x0C3FFFFF (2MB) ---- */
    L2_SRAM_0 :  o = 0x00800000 l = 0x00080000   /* 512kB internal SRAM */
    L2_SRAM_1 :  o = 0x00880000 l = 0x00080000   /* 512kB internal SRAM */
/*    MSMC_SRAM :  o = 0x0C000000 l = 0x00100000   /* 1MB MSMC Shared SRAM */
    MSMC_SRAM_A :  o = 0x0C200000 l = 0x00001000
    MSMC_SRAM_B :  o = 0x0C201000 l = 0x001FF000

/*    DDR0      :  o = 0x80000000 l = 0x80000000   /* 2GB external DDR0 */
	DDR_C   : origin = 0x80f00000, length = 0x100000

}

SECTIONS
{
	.root : {} > MSMC_SRAM_A

	GROUP: > MSMC_SRAM_B
	{
		.info
		.vectors
		.cinit
		.const
		.switch
		.text
		.romend

		.stack
		.firm

		.far
		.fardata
		.bss
		.neardata
	.cio
	.data
	.sysmem
	.args
	.ppinfo
	.ppdata
	.pinit
	.binit
	.init_array
	.rodata
	.c6xabi.exidx
	.c6xabi.extab
		.objects
		.heap
	}

	.noncache > DDR_C
}



What is the root cause of the errors?

Thanks and regards,
Koichiro Tashiro

  • Hi,

    Can you suggest them to try with this target configuration file:
       https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/NewTargetConfiguration_5F00_K2H.ccxml

    I've seen similar issues caused by wrong target configuration files used in CCS.

    Best Regards,
    Yordan

  • Hi Yordan,

    Customer tried the target configuration you suggested, but the result was the same.

    C66xx_0: Trouble Writing Register PC: (Error -1176 @ 0x0) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.903.2) 
    C66xx_0: Symbol Manager: the object file contains multiple sets of debug information; only the first set will be used.
    C66xx_0: Trouble Setting Breakpoint with the Action "Terminate Program Execution" at 0x86760: (Error -1176 @ 0x8677C) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.903.2) 
    C66xx_0: Breakpoint Manager: Retrying with a AET breakpoint
    C66xx_0: Trouble Setting Breakpoint with the Action "Finish Auto Run" at 0x85b20: (Error -1176 @ 0x85B3C) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 8.0.903.2) 
    C66xx_0: Breakpoint Manager: Retrying with a AET breakpoint
    

    Customer also tried a few things and got below results.
    a) Linker option “–relocatable” is removed.
    Linker errors are generated.
    Building target: "DMain.out"
    Invoking: C6000 Linker
    Flags: -mv6500 -Ooff -g --diag_warning=225 --diag_wrap=off --display_error_number -z -m"DMain.map" -i"C:/ti/ccsv8/tools/compiler/ti-cgt-c6000_8.2.5/lib" -i"C:/ti/ccsv8/tools/compiler/ti-cgt-c6000_8.2.5/include" --reread_libs --diag_wrap=off --display_error_number --warn_sections --xml_link_info="DMain_linkInfo.xml" --rom_model
    "C:/ti/ccsv8/tools/compiler/ti-cgt-c6000_8.2.5/bin/cl6x" -@"ccsLinker.opt" -o "DMain.out"
    <Linking>
    c60_abi.c:161:internal warning #10282: (".firm")
    c60_abi.c:161:internal warning #10282: (".bss")
    c60_abi.c:161:internal warning #10282: (".neardata")
    warning #10419-D: "GROUP_1" contains both ".cinit" and ".firm"; compression "rle" can not be performed for ".firm"
    warning #10419-D: "GROUP_1" contains both ".cinit" and ".far"; compression "rle" can not be performed for ".far"
    warning #10419-D: "GROUP_1" contains both ".cinit" and ".fardata"; compression "rle" can not be performed for ".fardata"
    warning #10419-D: "GROUP_1" contains both ".cinit" and ".bss"; compression "rle" can not be performed for ".bss"
    warning #10419-D: "GROUP_1" contains both ".cinit" and ".neardata"; compression "rle" can not be performed for ".neardata"
    warning #10419-D: "GROUP_1" contains both ".cinit" and ".objects"; compression "rle" can not be performed for ".objects"
    fatal error #10333: illegal attempt to place ".cinit" before ".objects" in "GROUP_1"
     
    >> Compilation failure
    makefile:483: recipe for target 'DMain.out' failed
    gmake[1]: *** [DMain.out] Error 1
    makefile:479: recipe for target 'all' failed
    gmake: *** [all] Error 2
    
    **** Build Finished ****
    

    b) Linker option “–relocatable” is removed.
    And move all sections with warning (line#9 to #14 in LinkerError.txt) *before* “.cinit”.
    No linker errors are generated.

    c) Linker option “–relocatable” is removed.
    And “MSMC_SRAM_B” area in linker command file is divided into two blocks (B and C).
    Please refer attached command file.
    /****************************************************************************/
    /*  66AK2Gxx_C66.cmd                                                        */
    /*  Copyright (c) 2016  Texas Instruments Incorporated                      */
    /*  Author: Rafael de Souza                                                 */
    /*                                                                          */
    /*    Description: This file is a sample linker command file that can be    */
    /*                 used for linking programs built with the C compiler and  */
    /*                 running the resulting .out file on the C66x DSP core of  */
    /*                 a 66AK2Gxx device.                                       */
    /*                 Use it as a guideline.  You will want to                 */
    /*                 change the memory layout to match your specific          */
    /*                 target system.  You may want to change the allocation    */
    /*                 scheme according to the size of your program.            */
    /*                                                                          */
    /****************************************************************************/
    -c
    -stack 0x4000
    
    MEMORY
    {
        /* ---- DSP 0: 0x0C200000 - 0x0C3FFFFF (2MB) ---- */
        L2_SRAM_0 :  o = 0x00800000 l = 0x00080000   /* 512kB internal SRAM */
        L2_SRAM_1 :  o = 0x00880000 l = 0x00080000   /* 512kB internal SRAM */
    /*    MSMC_SRAM :  o = 0x0C000000 l = 0x00100000   /* 1MB MSMC Shared SRAM */
        MSMC_SRAM_A :  o = 0x0C200000 l = 0x00001000
        MSMC_SRAM_B :  o = 0x0C201000 l = 0x000FF000
        MSMC_SRAM_C :  o = 0x0C300000 l = 0x00100000
    
    /*    DDR0      :  o = 0x80000000 l = 0x80000000   /* 2GB external DDR0 */
    	DDR_C   : origin = 0x80f00000, length = 0x100000
    
    }
    
    SECTIONS
    {
    	.root : {} > MSMC_SRAM_A
    
    	GROUP: > MSMC_SRAM_B
    	{
    		.info
    		.vectors
    		.cinit
    		.const
    		.switch
    		.text
    		.romend
    
    	}
    	GROUP: > MSMC_SRAM_C
    	{
    		.stack
    		.firm
    
    		.far
    		.fardata
    		.bss
    		.neardata
    	.cio
    	.data
    	.sysmem
    	.args
    	.ppinfo
    	.ppdata
    	.pinit
    	.binit
    	.init_array
    	.rodata
    	.c6xabi.exidx
    	.c6xabi.extab
    		.objects
    		.heap
    	}
    
    	.noncache > DDR_C
    }
    
    
    

    No linker errors are generated and the *.out file is properly loaded and executed.

    Questions:
    1) The *.out generated with “--relocatable” cannot be loaded / executed?
    2) Why placing “.far”, “.firm” etc. *after* “.cinit” generates linker errors?
    3) Is there any ways to put “.far”, “.firm” etc. *after* “.cinit” other than dividing MEMORY?


    Thanks and regards,
    Koichiro Tashiro

  • Tashiro-san,

    If you review the map file the customer has provided, you will notice in the section "GLOBAL SYMBOLS: SORTED BY Symbol Address " that there are several symbols that are being defined at addresses that are not available in the DSP memory. I am not sure if the linker is placing these or if the code has them located in that memory. For example the symbol "ISensorStartTransManual" is located at address 0x00002190. which is reserved for DSP view:

    Can you please confirm the customer has set the EVM in No boot/Debug boot mode. Please report the value of SW1 on the EVM or DEVSTAT register (0x26200020). I am also curious on what project is being run in their setup. The device in question is K2H06 but the linker command file refers to K2G. Does the issue always occur only when code is loaded to DDR or L2 but not when loaded into MSMC.. 

    Regarding the --relocatable and placement of the linker command file sections, you would need to post these on the TI Compiler/CCS forums.  We generally use absolute linked binaries for executing code on the DSP. the only place that I was able to find any information on use of relocatable binaries is older multicore image generation wiki located here:

    https://processors.wiki.ti.com/index.php/DSP/BIOS_on_Multi-Core_sharedimage

    Why is there a requirement to use relocatable binaries in the customer use case. Is this a single core or multicore application?

    Regards,

    Rahul

  • Hi Rahul,

    Please find below feedback from customer.

    “--relocatable” option is not needed for customer. So please forget about it.

    DEVSTAT value is 0x02000001.

    Regarding *.cmd file, customer uses K2G file just because there is no *.cmd file for K2H.
    (do we have K2H command file somewhere?)
    I thought the memory region used by customer for now is the same for both K2G and K2H.

    Thanks and regards,
    Koichiro Tashiro

  • Tashiro-san,

    Is there still any issue with loading the code on C66x cores on K2H ? With --relocatable option removed and loading code in MSMC memory, does the code load fine on the C66x cores.

    Regards,

    Rahul

  • Hi Rahul,

    The issue still remains.
    Customer removed “--relocatable” option and put code in MSMC memory.
    But link error happens. Customer needs to use either below two workaround to avoid the error.
    (please refer to my Dec.12 comments for details)
    b) move all warning sections before .cinit
    c) divide MSMC_SRAM area in two sections and put all warning sections in the area .cinit is not loaded.

    Thanks and regards,
    Koichiro Tashiro

  • Tashiro-san,

    Is this issue still open with your customer or can the above mentioned workaround be used by them to proceed with further development on this project. 

    I have not heard any thing else from out compiler team on this issue so I don`t think there is anything else we can try from the build flag options to avoid this issue.

    Regards,

    Rahul

  • Hi Rahul,

    Yes. The question is still open.
    If above two workarounds are reasonable and there is no other way to avoid the issue, I can ask customer to close it.
    Please confirm.

    Thanks and regards,
    Koichiro Tashiro

  • Tashiro-san,

    Our compiler team doesn`t see any issues with the two workarounds specified and we don`t have any additional inputs or suggestions on other approaches to workaround this issue.  I will try to close this issue with the customer and try to see if they have any feedback on why this may or may not be workable solution.

    Regards

    Rahul