Problems Loading Executable with XDS100 on EVMC6678L

Brant Jameson

Hello C6000 Denizens,

I am using a EVMC6678L development board for a project, and I've been having some problems with the emulator. After several days of troubleshooting my emulator's connection, I've been able to connect to my dev board. While I was able to load, run and debug a simple Helloworld application before (the standard Hello project included with CCS). I can still connect to the emulator and, ostensibly, the DSP, but I'm now having problems loading the application into the board's memory. Here's the error message I receive in the console when I try to load the executable:

C66xx_0: Trouble Writing Memory Block at 0x8000 on Page 0 of Length 0x5ea0: The DTDMA memory request is not serviced by the HW memory system. This could be caused by the memory address specified does not exist in the specified memory/cache level. (Error -1190) @ 32768 (0x8000)
C66xx_0: GEL: File: C:\Brant\workspace\Hello\Debug\Hello.out: Load failed.

It looks as if the emulator is unable to load the application at that address. I've tried using the memory browser to manually program a few bytes with effectively the same result:

C66xx_0: Trouble Writing Memory Block at 0x8000 on Page 0 of Length 0x1: The IM memory request is not serviced by the HW memory system. This could be caused by the memory address specified does not exist in the specified memory/cache level. (Error -1176) @ 32768 (0x8000)

I'm fairly sure that 0x8000 exists on the system, and this is where I should be loading my application. Any ideas?

Thanks,

-Brant

over 13 years ago

0 Steve Tickle over 13 years ago

Prodigy 60 points

Hi,

I'm also having identical problems to the one described above.

I have a 6678l eval board that will work with a colleagues CCSv5 setup but not with mine, the hardware is ok, CCS is not. I previously had this working well and it has suddenly latched into a failure-to-load mode.

I've tried recreating numerous "Hello World" and example projects from CCS with no success.

I've performed the dbgjtag pathlength test described in other threads on this forum and I get The JTAG DR Given Data scan-test has succeeded". To me this indicates the driver is working and installed correctly.

I've tried removing the .TI directory in the Application Settings directory thinking this would allow the driver to re-detect the emulator. No change.

And until yesterday afternoon, everything was working Ok. Just to re-iterate, the hardware is ok, the driver seems installed ok, the CCS install was working, the projects were working well, but now I cant load any code onto the board.

SteveT

0 DanRinkes over 13 years ago in reply to Steve Tickle

TI__Expert 8055 points

Brant, Steve,

Please have a look at the 6678 Device Data Sheet http://www.ti.com/lit/ds/symlink/tms320c6678.pdf Specifically, look at the memory map section. Memory from 0x00000000 - 0x007FFFFF is reserved. Local L2SRAM starts at 0x00800000.

Is this a hello world that was shipped with either CCS or the MCSDK? I've seen this issue once before. It seems like the memory definition is incorrect, either in the linker command file, or in the RTSC configuration (if there is one). Making this correct and then rebuilding should solve this issue. When you built the .out, it's likely that a .map file was created in the same directory which shows where everything was allocated. If you take this file and compare to the memory map in the data sheet, this should make some sense.

Regards,

Dan

0 Steve Tickle over 13 years ago in reply to DanRinkes

Prodigy 60 points

In my case, I doubt very much this is the issue.

The HelloWorld was a CCS generated one that has worked before and does work on other boards. I've also repeatedly regenerated it in my attempts to get the boards working. Unless the settings that CCS generated have suddenly changed overnight I doubt this can be the issue unfortunately.

Also, I've also tried the EVM with a 560v2 mezannine emu that previously worked. This too is behaving the same way (i.e. failing to load the code).

I've also tried with ad without GEL scripts for the EVM, all cases fail.

Another machine that was working (my laptop) has now hit this same issue.

SteveT

0 DanRinkes over 13 years ago in reply to Steve Tickle

TI__Expert 8055 points

Steve,

You said: "I'm also having identical problems to the one described above."

Brant said the error message was : C66xx_0: Trouble Writing Memory Block at 0x8000 on Page 0 of Length 0x5ea0: The DTDMA memory request is not serviced by the HW memory system. This could be caused by the memory address specified does not exist in the specified memory/cache level. (Error -1190) @ 32768 (0x8000)"

Are you getting the identical message? The emulator should not be trying to write that address if there is no code linked to that location.

Can you post the .map file that was generated?

Dan

0 Brant Jameson over 13 years ago in reply to DanRinkes

Intellectual 350 points

Hi Dan,

I resolved my problem regarding the loading of code, Helloworld and otherwise, onto my eval board using the XDS100 emulator. I think the problem may have something to do with the fact that I have two different installations of CCS on my system. This was unfortunately required due to the way GNU make handles paths in the Windows XP environment.

There are two hurdles to overcome when building a project using GNU make in WinXP: the way GNU make handles the path separator is different from the way Windows handles its path separator. GNU make wants to use the POSIX separator '/' and Windows wants to use the Windows separator '\'. Unfortunately, GNU make interprets the windows separator as an escape character, and is thus incapable of resolving any path which contains spaces. Since the default installation directory is C:\Program Files\Texas Instruments\ccs it was, at least for me, impossible to use the compiler tools with GNU make. Thus, I had to install CCS at C:\TI\ccs instead. I use the latter path for make, and since that installation occurred last, it was the default CCS installation that launched when I clicked on the CCS shortcut (which actually launches eclipse.exe).

The first installation can load programs onto the DSP using the emulator, while the second cannot. No idea why, I'd be willing to help you troubleshoot that if you have any ideas on what to look for.

Now, my second, and somewhat inter-related problem involves getting my code to begin executing from main. Helloworld builds and runs just fine, as well as the additional functions that I add to the project, but when I load my custom makefile g platformFileIO.out application (custom makefile built application) it begins executing the code from a random function AMF_Limiter_Init, as opposed to main. I've attached my .map file. Perhaps you can help me link this code properly, or determine what code/symbol offset needs to be used to load the application, and run the application from int_00 entry point.

Thanks,

-Brant

PS: I tried to attach the .map file and the wiki returned an error saying that file type is not allowed. Thus I've pasted the contents of the .map file below. Sorry for the inconvenince.

******************************************************************************
               TMS320C6x Linker PC v7.2.1
******************************************************************************
>> Linked Fri Sep 30 10:51:02 2011

OUTPUT FILE NAME:   <platform_file_io.out>
ENTRY POINT SYMBOL: "_c_int00" address: 003f20e0

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
---------------------- -------- --------- -------- -------- ---- --------
NEARRAM               00000001   00007fff 00000004 00007ffb RWIX
RAM                   00008000   fffffffe 003fe274 ffc01d8a RWIX

0 DanRinkes over 13 years ago in reply to Brant Jameson

TI__Expert 8055 points

Brant,

Thanks for attaching that file. (FYI, I should have said this, but all I really needed was the top few lines)

From these lines, I can see that the code is linked to locations that are marked as Reserved in the 6678 memory map.

>> Linked Fri Sep 30 10:51:02 2011

OUTPUT FILE NAME:   <platform_file_io.out>
ENTRY POINT SYMBOL: "_c_int00" address: 003f20e0

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
---------------------- -------- --------- -------- -------- ---- --------
NEARRAM               00000001   00007fff 00000004 00007ffb RWIX
RAM                   00008000   fffffffe 003fe274 ffc01d8a RWIX

Can you post the contents of your linker command file for this project?

FYI, the default behavior for CCSv5 is to load the application, set the entry point to c_int00 and then run to main (and halt there). You can change this behavior by going in to Tools->Debugger Options->Generic Debugger Options and then ensuring that the two boxes in the "Auto Run" options are unchecked. I'm trying to figure out if the entry point is getting set correctly or not. From the highlighted part of the linker command file, it should be set at c_int00.

I'm still concerned, if this is the .map file, that the code contained in it is being linked at 0x8000. (That's where main is located). I'm confused as to how you are getting this code to even load if the memory configuration above is correct. I suspect a fix to the linker command file will fix this.

Regards,

Dan

0 Brant Jameson over 13 years ago in reply to DanRinkes

Intellectual 350 points

Here you go!

C:/TI/ccsv5/tools/compiler/c6000/bin/cl6x -g -mv6600 -m"platformFileIO.map -i"C:/TI/ccsv5/tools/compiler/c6000/lib" -i"C:/TI/ccsv5/tools/compiler/c6000/include" -mv6600 -g --diag_warning=225 --abi=eabi -z -m"platformFileIO.map" --warn_sections -i"C:/TI/ccsv5/tools/compiler/c6000/lib" -i"C:/TI/ccsv5/tools/compiler/c6000/include" --reread_libs --rom_model --run_linker --rom_model --output_file=platform_file_io.out main.o DoControlCode.o preset.o --library=platformFileIO.lib --library=C:/TI/ccsv5/tools/compiler/c6000/lib/rts6600_elf.lib

-Brant

0 DanRinkes over 13 years ago in reply to Brant Jameson

TI__Expert 8055 points

This is not the linker command file. This is the command line sent to the compiler. The Linker Command file is the file that specifies where stuff gets linked. Your command line should specify which linker command file to use, and it doesn't specify any. So, I suspect that this is using some default link locations, which aren't correct for this target. See the compiler users guide for more info on linker command files.

Regards,

Dan

0 Brant Jameson over 13 years ago in reply to DanRinkes

Intellectual 350 points

Hi Dan,

There's a series of confidential information contained in the linker information file. Since you're a TI employee, I was wondering if I could send this to you via secure email?

-Brant

0 Jonathan White over 13 years ago in reply to Brant Jameson

Intellectual 830 points

I once got a .map file from a TI "hello world" example that looked like the once posted above:

MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
---------------------- -------- --------- -------- -------- ---- --------
NEARRAM               00000001   00007fff 00000004 00007ffb RWIX
RAM                   00008000   fffffffe 003fe274 ffc01d8a RWIX

The problem was that the name of my linker command file (in Project->Properies->CCS-Build->General->LinkerCommandFile had accidentally been blanked out (due to a CCS problem when switching from COFF to ELF symbols), and the linker was (it seems) using some internal defaults

When I re-entered the correct name of the linker .cmd file, the problem went away. The map should look more like the one below:

MEMORY CONFIGURATION

name origin length used unused attr fill

---------------------- -------- --------- -------- -------- ---- --------

L2SRAM 00800000 00080000 00058648 000279b8 RW X

MSMCSRAM 0c000000 00400000 00000000 00400000 RW X

DDR3 80000000 20000000 000a6358 1ff59ca8 RWIX

Maybe you have the same issue.

0 Brant Jameson over 13 years ago in reply to Jonathan White

Intellectual 350 points

Well,

I'm using a makefile based project as opposed to the built in CCS project manager. There's no .cmd file in the project directory, and I think the memory map will ultimately be determined by the commands that are used to link the project. There has to be a similar technique for passing these parameters to the linker through the makefile, as I'm sure the same compiler and linker are used in both situations. It's just not clear what those commands are, or what their parameters would be.

-Brant

0 DanRinkes over 13 years ago in reply to Brant Jameson

TI__Expert 8055 points

Brant,

I agree with you. There has to be some analogous functionality in the make file. I'm not familiar enough with make files to know where this goes. I can tell you this. The linker command file is passed to the compiler with the -l switch (lowercase L).

-l "..\path_to_linker_command_file"

Regards,
Dan

0 DanRinkes over 13 years ago in reply to DanRinkes

TI__Expert 8055 points

Brant,

I got the XML file that you sent. This file is not a linker command file either. I believe this is the a file that is generated by the linker. It has all of the addresses that are assigned to each section. The linker command file looks something like what is below.

This is what tells the linker where memory is located in your target. You have to have something similar to it. If you're using RTSC, it will create this for you based on your target. If you aren't using RTSC, then you have to create it. If you don't, the linker will just put stuff in some default location. Again, please see the Compiler guide for information on how to create the linker command file. If you're using the 6678 LCEVM, you might be able to use the file I embedded below. Again, it it passed to the compiler with the command -l "..\path_to_linker_command_file" This is a very simple linker command file. You should modify it to fit your needs.

Looking at the XML file, I can see that the symbol c_int00 is being linked to location 0x3f16c0. As I mentioned earlier, this is not valid memory on the 6678. This is the same address that the .map file that you sent earlier reported.

<load_address>0x3f16c0</load_address>

<run_address>0x3f16c0</run_address>

Regards,

Dan

/******************************************************************************/

/* link_6678.cmd */

/* Automated Revision Information */

/* Changed: $LastChangedDate: 2011-05-10 14:20:09 -0400 (Tue, 10 May 2011) $ */

/* Revision: $LastChangedRevision: 10153 $ */

/******************************************************************************/

-stack 0x800

-heap 0x800

MEMORY

{

SRAM1: o=0x00e00000 l=0x00004000 /* 16K of SRAM */

SRAM2: o=0x00800000 l=0x00040000 /* 256K of SRAM */

L1D: o=0x00f00000 l=0x00008000 /* 32K of L1D Cache */

L1P: o=0x00e04000 l=0x00004000 /* 16K of L1P Cache */

L2: o=0x00840000 l=0x00040000 /* 256K of L2 Cache */

RESMEM: o=0xE0000000 l=0x01000000

}

SECTIONS

{

.bss > SRAM2

.far > SRAM2

.text > SRAM2

.cinit > SRAM2

.const > SRAM2

.stack > SRAM2

.cio > SRAM2

.sysmem > SRAM2

.switch > SRAM2

.fardata > SRAM2

.neardata > SRAM2

.rodata > SRAM2

}

0 Brant Jameson over 13 years ago in reply to DanRinkes

Intellectual 350 points

Hi Dan,

Figured this out a couple of days ago. We generated our code using the attached .cmd file. Hopefully this helps someone else.

-Brant

/****************************************************************************/

/* C6678.cmd */

/* */

/* 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 an C6678 */

/* device. Use it as a guideline. You will want to */

/* change the memory layout to match your specific C6xxx */

/* target system. You may want to change the allocation */

/* scheme according to the size of your program. */

/* */

/****************************************************************************/

-stack 0x2000

-heap 0x8000

MEMORY

{

SHRAM: origin = 0x0C000000 length = 0x00400000 /* 4MB Multicore shared Memmory */

CORE0_L2_SRAM: origin = 0x10800000 length = 0x00080000 /* 512kB CORE0 L2/SRAM */

CORE0_L1P_SRAM: origin = 0x10E00000 length = 0x00008000 /* 32kB CORE0 L1P/SRAM */

CORE0_L1D_SRAM: origin = 0x10F00000 length = 0x00008000 /* 32kB CORE0 L1D/SRAM */

CORE1_L2_SRAM: origin = 0x11800000 length = 0x00080000 /* 512kB CORE1 L2/SRAM */

CORE1_L1P_SRAM: origin = 0x11E00000 length = 0x00008000 /* 32kB CORE1 L1P/SRAM */

CORE1_L1D_SRAM: origin = 0x11F00000 length = 0x00008000 /* 32kB CORE1 L1D/SRAM */

CORE2_L2_SRAM: origin = 0x12800000 length = 0x00080000 /* 512kB CORE2 L2/SRAM */

CORE2_L1P_SRAM: origin = 0x12E00000 length = 0x00008000 /* 32kB CORE2 L1P/SRAM */

CORE2_L1D_SRAM: origin = 0x12F00000 length = 0x00008000 /* 32kB CORE2 L1D/SRAM */

CORE3_L2_SRAM: origin = 0x13800000 length = 0x00080000 /* 512kB CORE3 L2/SRAM */

CORE3_L1P_SRAM: origin = 0x13E00000 length = 0x00008000 /* 32kB CORE3 L1P/SRAM */

CORE3_L1D_SRAM: origin = 0x13F00000 length = 0x00008000 /* 32kB CORE3 L1D/SRAM */

CORE4_L2_SRAM: origin = 0x14800000 length = 0x00080000 /* 512kB CORE4 L2/SRAM */

CORE4_L1P_SRAM: origin = 0x14E00000 length = 0x00008000 /* 32kB CORE4 L1P/SRAM */

CORE4_L1D_SRAM: origin = 0x14F00000 length = 0x00008000 /* 32kB CORE4 L1D/SRAM */

CORE5_L2_SRAM: origin = 0x15800000 length = 0x00080000 /* 512kB CORE5 L2/SRAM */

CORE5_L1P_SRAM: origin = 0x15E00000 length = 0x00008000 /* 32kB CORE5 L1P/SRAM */

CORE5_L1D_SRAM: origin = 0x15F00000 length = 0x00008000 /* 32kB CORE5 L1D/SRAM */

CORE6_L2_SRAM: origin = 0x16800000 length = 0x00080000 /* 512kB CORE6 L2/SRAM */

CORE6_L1P_SRAM: origin = 0x16E00000 length = 0x00008000 /* 32kB CORE6 L1P/SRAM */

CORE6_L1D_SRAM: origin = 0x16F00000 length = 0x00008000 /* 32kB CORE6 L1D/SRAM */

CORE7_L2_SRAM: origin = 0x17800000 length = 0x00080000 /* 512kB CORE7 L2/SRAM */

CORE7_L1P_SRAM: origin = 0x17E00000 length = 0x00008000 /* 32kB CORE7 L1P/SRAM */

CORE7_L1D_SRAM: origin = 0x17F00000 length = 0x00008000 /* 32kB CORE7 L1D/SRAM */

EMIF16_CS2: origin = 0x70000000 length = 0x04000000 /* 64MB EMIF16 CS2 Data Memory */

EMIF16_CS3: origin = 0x74000000 length = 0x04000000 /* 64MB EMIF16 CS3 Data Memory */

EMIF16_CS4: origin = 0x78000000 length = 0x04000000 /* 64MB EMIF16 CS4 Data Memory */

EMIF16_CS5: origin = 0x7C000000 length = 0x04000000 /* 64MB EMIF16 CS5 Data Memory */

CORE0_DDR3: origin = 0x80000000 length = 0x10000000 /* 256MB DDR3 SDRAM for CORE0 */

CORE1_DDR3: origin = 0x90000000 length = 0x10000000 /* 256MB DDR3 SDRAM for CORE1 */

CORE2_DDR3: origin = 0xA0000000 length = 0x10000000 /* 256MB DDR3 SDRAM for CORE2 */

CORE3_DDR3: origin = 0xB0000000 length = 0x10000000 /* 256MB DDR3 SDRAM for CORE3 */

CORE4_DDR3: origin = 0xC0000000 length = 0x10000000 /* 256MB DDR3 SDRAM for CORE4 */

CORE5_DDR3: origin = 0xD0000000 length = 0x10000000 /* 256MB DDR3 SDRAM for CORE5 */

CORE6_DDR3: origin = 0xE0000000 length = 0x10000000 /* 256MB DDR3 SDRAM for CORE6 */

CORE7_DDR3: origin = 0xF0000000 length = 0x10000000 /* 256MB DDR3 SDRAM for CORE7 */

}

SECTIONS

{

#ifdef CORE0

.text > CORE0_L2_SRAM

.stack > CORE0_L2_SRAM

.bss > CORE0_L2_SRAM

.cio > CORE0_L2_SRAM

.const > CORE0_L2_SRAM

.data > CORE0_L2_SRAM

.switch > CORE0_L2_SRAM

.sysmem > CORE0_L2_SRAM

.far > CORE0_L2_SRAM

.args > CORE0_L2_SRAM

.ppinfo > CORE0_L2_SRAM

.ppdata > CORE0_L2_SRAM

/* COFF sections */

.pinit > CORE0_L2_SRAM

.cinit > CORE0_L2_SRAM

/* EABI sections */

.binit > CORE0_L2_SRAM

.init_array > CORE0_L2_SRAM

.neardata > CORE0_L2_SRAM

.fardata > CORE0_L2_SRAM

.rodata > CORE0_L2_SRAM

.c6xabi.exidx > CORE0_L2_SRAM

.c6xabi.extab > CORE0_L2_SRAM

#endif

#ifdef CORE1

.text > CORE1_L2_SRAM

.stack > CORE1_L2_SRAM

.bss > CORE1_L2_SRAM

.cio > CORE1_L2_SRAM

.const > CORE1_L2_SRAM

.data > CORE1_L2_SRAM

.switch > CORE1_L2_SRAM

.sysmem > CORE1_L2_SRAM

.far > CORE1_L2_SRAM

.args > CORE1_L2_SRAM

.ppinfo > CORE1_L2_SRAM

.ppdata > CORE1_L2_SRAM

/* COFF sections */

.pinit > CORE1_L2_SRAM

.cinit > CORE1_L2_SRAM

/* EABI sections */

.binit > CORE1_L2_SRAM

.init_array > CORE1_L2_SRAM

.neardata > CORE1_L2_SRAM

.fardata > CORE1_L2_SRAM

.rodata > CORE1_L2_SRAM

.c6xabi.exidx > CORE1_L2_SRAM

.c6xabi.extab > CORE1_L2_SRAM

#endif

#ifdef CORE2

.text > CORE2_L2_SRAM

.stack > CORE2_L2_SRAM

.bss > CORE2_L2_SRAM

.cio > CORE2_L2_SRAM

.const > CORE2_L2_SRAM

.data > CORE2_L2_SRAM

.switch > CORE2_L2_SRAM

.sysmem > CORE2_L2_SRAM

.far > CORE2_L2_SRAM

.args > CORE2_L2_SRAM

.ppinfo > CORE2_L2_SRAM

.ppdata > CORE2_L2_SRAM

/* COFF sections */

.pinit > CORE2_L2_SRAM

.cinit > CORE2_L2_SRAM

/* EABI sections */

.binit > CORE2_L2_SRAM

.init_array > CORE2_L2_SRAM

.neardata > CORE2_L2_SRAM

.fardata > CORE2_L2_SRAM

.rodata > CORE2_L2_SRAM

.c6xabi.exidx > CORE2_L2_SRAM

.c6xabi.extab > CORE2_L2_SRAM

#endif

#ifdef CORE3

.text > CORE3_L2_SRAM

.stack > CORE3_L2_SRAM

.bss > CORE3_L2_SRAM

.cio > CORE3_L2_SRAM

.const > CORE3_L2_SRAM

.data > CORE3_L2_SRAM

.switch > CORE3_L2_SRAM

.sysmem > CORE3_L2_SRAM

.far > CORE3_L2_SRAM

.args > CORE3_L2_SRAM

.ppinfo > CORE3_L2_SRAM

.ppdata > CORE3_L2_SRAM

/* COFF sections */

.pinit > CORE3_L2_SRAM

.cinit > CORE3_L2_SRAM

/* EABI sections */

.binit > CORE3_L2_SRAM

.init_array > CORE3_L2_SRAM

.neardata > CORE3_L2_SRAM

.fardata > CORE3_L2_SRAM

.rodata > CORE3_L2_SRAM

.c6xabi.exidx > CORE3_L2_SRAM

.c6xabi.extab > CORE3_L2_SRAM

#endif

#ifdef CORE4

.text > CORE4_L2_SRAM

.stack > CORE4_L2_SRAM

.bss > CORE4_L2_SRAM

.cio > CORE4_L2_SRAM

.const > CORE4_L2_SRAM

.data > CORE4_L2_SRAM

.switch > CORE4_L2_SRAM

.sysmem > CORE4_L2_SRAM

.far > CORE4_L2_SRAM

.args > CORE4_L2_SRAM

.ppinfo > CORE4_L2_SRAM

.ppdata > CORE4_L2_SRAM

/* COFF sections */

.pinit > CORE4_L2_SRAM

.cinit > CORE4_L2_SRAM

/* EABI sections */

.binit > CORE4_L2_SRAM

.init_array > CORE4_L2_SRAM

.neardata > CORE4_L2_SRAM

.fardata > CORE4_L2_SRAM

.rodata > CORE4_L2_SRAM

.c6xabi.exidx > CORE4_L2_SRAM

.c6xabi.extab > CORE4_L2_SRAM

#endif

#ifdef CORE5

.text > CORE5_L2_SRAM

.stack > CORE5_L2_SRAM

.bss > CORE5_L2_SRAM

.cio > CORE5_L2_SRAM

.const > CORE5_L2_SRAM

.data > CORE5_L2_SRAM

.switch > CORE5_L2_SRAM

.sysmem > CORE5_L2_SRAM

.far > CORE5_L2_SRAM

.args > CORE5_L2_SRAM

.ppinfo > CORE5_L2_SRAM

.ppdata > CORE5_L2_SRAM

/* COFF sections */

.pinit > CORE5_L2_SRAM

.cinit > CORE5_L2_SRAM

/* EABI sections */

.binit > CORE5_L2_SRAM

.init_array > CORE5_L2_SRAM

.neardata > CORE5_L2_SRAM

.fardata > CORE5_L2_SRAM

.rodata > CORE5_L2_SRAM

.c6xabi.exidx > CORE5_L2_SRAM

.c6xabi.extab > CORE5_L2_SRAM

#endif

#ifdef CORE6

.text > CORE6_L2_SRAM

.stack > CORE6_L2_SRAM

.bss > CORE6_L2_SRAM

.cio > CORE6_L2_SRAM

.const > CORE6_L2_SRAM

.data > CORE6_L2_SRAM

.switch > CORE6_L2_SRAM

.sysmem > CORE6_L2_SRAM

.far > CORE6_L2_SRAM

.args > CORE6_L2_SRAM

.ppinfo > CORE6_L2_SRAM

.ppdata > CORE6_L2_SRAM

/* COFF sections */

.pinit > CORE6_L2_SRAM

.cinit > CORE6_L2_SRAM

/* EABI sections */

.binit > CORE6_L2_SRAM

.init_array > CORE6_L2_SRAM

.neardata > CORE6_L2_SRAM

.fardata > CORE6_L2_SRAM

.rodata > CORE6_L2_SRAM

.c6xabi.exidx > CORE6_L2_SRAM

.c6xabi.extab > CORE6_L2_SRAM

#endif

#ifdef CORE7

.text > CORE7_L2_SRAM

.stack > CORE7_L2_SRAM

.bss > CORE7_L2_SRAM

.cio > CORE7_L2_SRAM

.const > CORE7_L2_SRAM

.data > CORE7_L2_SRAM

.switch > CORE7_L2_SRAM

.sysmem > CORE7_L2_SRAM

.far > CORE7_L2_SRAM

.args > CORE7_L2_SRAM

.ppinfo > CORE7_L2_SRAM

.ppdata > CORE7_L2_SRAM

/* COFF sections */

.pinit > CORE7_L2_SRAM

.cinit > CORE7_L2_SRAM

/* EABI sections */

.binit > CORE7_L2_SRAM

.init_array > CORE7_L2_SRAM

.neardata > CORE7_L2_SRAM

.fardata > CORE7_L2_SRAM

.rodata > CORE7_L2_SRAM

.c6xabi.exidx > CORE7_L2_SRAM

.c6xabi.extab > CORE7_L2_SRAM

#endif

}

Processors

Processors forum

Problems Loading Executable with XDS100 on EVMC6678L