TM4C1299NCZAD: TM4C1299

Hi Lezhong,

  Can you provide more information? Can you show your before and after linker command files?

  How big is your SDRAM?

  How big is final binary file to be loaded to SDRAM?

  You said you increase more obj files. What if you only add one obj file at a time? After how many additional obj files you added result in the error you see?

  Are you saying loading the new binary to the SDRAM is working? What is not working is running the code from SDRAM?

Thanks Charles.

The SDRAM is 32M bytes.  The binary file is about 200K Bytes.  I added one by one.  But when I added one specific obj, I got the error message.

The error message is during loading the binary to the SDRAM.  I re-attached the messge:

CORTEX_M4_0: GEL Output:
Memory Map Initialization Complete
CORTEX_M4_0: File Loader: Verification failed: Values at address 0x61017FD1 do not match Please verify target memory and memory map.
CORTEX_M4_0: GEL: File: C:\CCS_DEPC_repo\master_2g5\de-platform\DE-Platform\Debug\DE-Platform.out: a data verification error occurred, file load failed.

I did not see the attached file button here.  So I pasted the linker command file content here.  There are few obj files in the ext_code section.  I added the first 2 files, it works.  But when I added the third one, it shows the above error.

#ifdef LINKER_BOOTLOADER_BASE_HIGH // For debug build: defined in properties -> CCS Build -> Arm Linker -> Advanced Options -> Command File Preprocessing
#define BOOTLOADER_BASE 0x000F8000 // It is a special build only for using with application code in debug build
#define APP_BASE 0x00000000
#else
#define BOOTLOADER_BASE 0x00000000 // Both debug and release build
#define APP_BASE 0x00008000
#endif /* LINKER_BOOTLOADER_BASE_HIGH */

#define BOOTLOADER_SIZE 0x00008000 // 32KB
#define APP_SIZE 0x000f8000 // Total - bootloader = 1M - 32K = 992K
#define RAM_BASE 0x20000000
#define RAM_SIZE 0x00040000

/* External SDRAM */
#define SDRAM_START_ADDRESS 0x60000000 // Decide when initialize the EPI with EPI_ADDR_RAM_BASE_6
#define SDRAM_TOTAL_SIZE 0x02000000 // 256M Bits = 32M Bytes
#define SDRAM_DATA_SIZE 0x01000000 // 16M Bytes
#define SDRAM_CODE_SIZE SDRAM_TOTAL_SIZE - SDRAM_DATA_SIZE

/* System memory map */

MEMORY
{
/* Application stored in and executes from internal flash */
FLASH (RX) : origin = APP_BASE, length = APP_SIZE
/* Application uses internal RAM for data */
SRAM (RWX) : origin = RAM_BASE, length = RAM_SIZE

/* LLin 2023-12-01: External SDRAM via EPI interface */
/* Split to 2 parts */
EPISDRAM_DATA (RWX) : origin = SDRAM_START_ADDRESS, length = SDRAM_DATA_SIZE
EPISDRAM_CODE (RWX) : origin = SDRAM_START_ADDRESS + SDRAM_DATA_SIZE, length = SDRAM_CODE_SIZE
}

/* Section allocation in memory */

SECTIONS
{
.intvecs: > APP_BASE
.text : > FLASH
.const : > FLASH
.cinit : > FLASH
.pinit : > FLASH
.init_array : > FLASH

.vtable : > RAM_BASE
//2022-07-29 TC: GROUP forces sections to be in the
//shown order. Linker will arrange by largest to
//smallest otherwise. When data < system, order
//switches, and we encounter memory corruption for
//currently unknown reason.
GROUP
{
.bss
.data
.sysmem
.stack
} > SRAM

/* External sections on external SDRAM via EPI */
/* Refer to NOTES in drv_epi.h for how to use the external SDRAM */

/* Define global variable on external SDRAM in this section */
ext_data : > EPISDRAM_DATA

/* Define code on external SDRAM in this section */
ext_code :
{
. = ALIGN(32);
_ext_code_start = .;
*(ext_code)
app_json_get_library.obj
app_json_post_library.obj
app_vsd_ivs101.obj
app_vsd_ivs.obj
_ext_code_end = . - 1;
} > EPISDRAM_CODE
}

__STACK_TOP = __stack + __STACK_SIZE;

Lezhong Lin said:

I added the first 2 files, it works.  But when I added the third one, it shows the above error.

You said the error is on address 0x61017FD1. If you look at the last 7 bits of the address 1017FD1, this is already more than 16MB. Maybe you didn't configure SDRAM size to accommodate this range. 

Have your reorder the object files? What is the result?

For experiment, what if the third object file is a very small file? I just wanted to know if the size of the third file has anything to do with it.

Can you repeat the same problem on another board? I wanted to rule out if the problem is related to SDRAM.  

Thanks Charles.

Actually, I have 32M Byte of SDRAM.  I split it into 2 X 16M.  From 0x60000000 to 0x60FFFFFF is for data.  From 0x61000000 to 0x61FFFFFF is for code.  So 0x61017FD1 is within the code range.

I reordered the object files.  For example, if I put *(ext_code) after the first app_json_get_library.obj.  During the test, I removed all other obj files.  It would not work even with only app_json_get_library.obj file.

The third object file is 20988 Bytes.  Its size is comparable with the other obj files.

Yes, we tried 2 boards.  We have the same issue at the same address.  I also tried different debug probes, BlackHawk and JLink.  Both of them do not work, but the reported problem address is different.  It seems that it is not hardware related.

Hi Lezhong,

  My understanding is that during your processor initialization, it would need to first setup the SDRAM module and copy the code and data to SDRAM through EPI interface. Is that correct? 

  I suppose the error you see is during the runtime, correct? In another word, it is not during compile. Correct me if I'm wrong. 

Thanks Charles,

I added the EPI initialization in ResetISR in startup.c before the call of _c_int00

void
ResetISR(void)
{
// Has to initialize EPI before _c_int00
// Otherwise will go to Hardfault directly
// Initialize the stack pointer
__set_MSP((uint32_t)&__STACK_END);

// Initialize the EPI and SDRAM
drv_epiInit();

//
// Jump to the CCS C initialization routine. This will enable the
// floating-point unit as well, so that does not need to be done here.
//
__asm(" .global _c_int00\n"
" b.w _c_int00");
}

It seems that the loading process is inside _c_int00.  So the error is neither in runtime nor in compile.  It is during loading the code into external SDRAM via _c_int00 when debugging.

The second thing is the error address is in the middle of the code range 0x610xxxxx.  If it is in the starting address 0x61000000, I may check GEL file or EPI initialization.  But it is in the middle of the code range.  It is weired.

Hi Lezhong,

  I may need to forward your question to our CCS expert if the problem occurs inside _c_int00. _c_init will initialize global variables and runs other chores. Can you clarify one more time if you are able build the CCS project successfully. I'm not clear when you say the problem is neither in compile nor in runtime. Maybe I should ask the questions as follows. Please provide your feedback for each one. 

 - Can you produce the .out file successfully? This is what I meant by compile. 

 - Can you load the .out file successfully to the internal flash? This is only the loading part, the processor has not run yet. 

 - After the processor starts running from ResetISR, it will produce the error on the console. Is this correct? This is where you said somehow error seems to happen in _c_int00. 

  - I will suppose you are creating some type of bootloader to first read code/data from some external NVM memory and then copy the code/data to the SDRAM. After the SDRAM is loaded, you change the program counter to SDRAM address to run code out of it. Is this a correct understanding?

Thanks Charles,

Please find the answers below:

 - Can you produce the .out file successfully? This is what I meant by compile. 

Yes, I can produce the .out file.

 - Can you load the .out file successfully to the internal flash? This is only the loading part, the processor has not run yet. 

Yes, I can load the .out file successfully to the internal flash.

 - After the processor starts running from ResetISR, it will produce the error on the console. Is this correct? This is where you said somehow error seems to happen in _c_int00. 

No, the processor does not start running from ResetISR before producing the error.

But we have the code already loaded in the previous debug session, so the EPI was initialized proper after powerup.  So the following debug session will always has the EPI ready and the SDRAM code should be able to be loaded into external SDRAM.

But now during the verification, the SDRAM is failed.  It is weird as the failed address is not at the first address of 0x61000000.

  - I will suppose you are creating some type of bootloader to first read code/data from some external NVM memory and then copy the code/data to the SDRAM. After the SDRAM is loaded, you change the program counter to SDRAM address to run code out of it. Is this a correct understanding?

No, we did not use your mentioned method to run SDRAM as it would be more complicated to do the debugging.

Lezhong Lin said:

But we have the code already loaded in the previous debug session, so the EPI was initialized proper after powerup.  So the following debug session will always has the EPI ready and the SDRAM code should be able to be loaded into external SDRAM.

Lezhong Lin said:

No, we did not use your mentioned method to run SDRAM as it would be more complicated to do the debugging.

The internal flash is only 1MB. Your SDRAM is 32MB. How can you load the SDRAM without using a bootloader to first copy the SDRAM code from an external NVM to the SDRAM and later run from SDRAM. How is the internal flash able to hold 32MB SDRAM code and data? Can you please clarify? Whether you loaded SDRAM in a previous debug session, somehow a mechanism must be in place to copy 32MB of code from somewhere to SDRAM, right?

Hi Iezhong,

  Really glad that you figure out the problem. Honestly, I have a hard time to diagnose the cause of the problem. Never thought about pin issue as you mentioned the only thing you changed was the linker file to include more obj files. 

Yes Charles, I never thought it as well.  The thing is it is not the first address of 0x61000000.  It is weired.

Anyway, please close this ticket.  And thank you so much for your timely help and supports.

Lezhong,

  Just one last thing for my knowledge. What is the simulator you are talking about? I may be wrong but I don't think CCS has a M4 simulator anymore. Or the GEL script is what you mean by the simulator? You first initialize EPI and SDRAM. The GEL script basically scan the LDR/STR instructions to the processor's debug logic via JTAG interface and ultimately it is the processor performing the read/write to the SDRAM in debug mode, not run mode. 

Thanks Charles for the information regarding to the code loading process.  I mean the simulator is the debug probe.  

We have the SDRAM code loading function in release build.