66AK2G12: DDR3 initialization overwrites first bytes of RAM

Andy Sifferman1

Part Number: 66AK2G12

Hello,

I am using CCS 10.4 and TI-RTOS with a custom board having a K2G and 512MB of DDR3. Most of our device initialization firmware uses the same code as the evmK2G examples. I've discovered a curious behavior with DDR3 initialization and would like to understand its origin and purpose.

I am using the CCS Debugger. I have written a small program that runs on the A15 core and resides entirely in internal L2 (MSMC) RAM (including stack, heap, and all variables). This program reads and writes a large buffer that I have positioned at the start of external L3 (DDR3) RAM, at address 0x80000000.

Here is the sequence of steps to produce the behavior.

1. Load the program into the target. The DDR3 section containing the large buffer is marked "NOLOAD" in the linker script, so nothing is loaded into the DDR3 buffer during this step. This step runs the evmk2g_arm.gel script, which initializes the EMIF controller (among other things). The debugger is set to Run to main().

2. Fill the DDR3 buffer with all zeros (0x00000000). I've discovered this can be done either from firmware, or from the Memory Browser window.

3. Start single-stepping the program from main(). The first function to execute is Board_init(), as shown in the below code:

#include "board/board.h"

int main()
{
    Board_initCfg boardCfg;

    boardCfg = BOARD_INIT_PLL | 
               BOARD_INIT_MODULE_CLOCK |
               BOARD_INIT_DDR |
               BOARD_INIT_PINMUX_CONFIG;

    Board_init(boardCfg);
    
    return 0;
}

Although the PLLs, clocks, and DDR were all configured in the GEL script, they are all re-configured in Board_init(). (I don't think this has any bearing on the behavior I'm seeing.)

4. Step into Board_init(), and continue stepping until reaching function Board_DDR3Init() in file ${PDK_INSTALL_DIR}/packages/ti/board/src/evmK2G/evmK2G_ddr.c.

5. With the Memory Browser window open to address 0x80000000, I can confirm that the buffer is still filled with zeros.

6. If I now step OVER function Board_DDR3Init(), the Memory browser shows that the first 64 bytes of DDR3 (the start of my large buffer) has been overwritten with the following pattern.

Further experimentation has shown that the same behavior occurs within the GEL script, too.

I would like to understand the source of this phenomenon, so I can have assurance that my data will not be overwritten at an inconvenient time.

Thank you.

over 4 years ago

0 Jianzhong Xu over 4 years ago

TI__Guru 62240 points

Hi Andy,

Board_DDR3Init() shouldn't write to the DDR memory because the memory could be filled with code or user data. I'm not sure why you saw that strange behavior. I have a few questions:

Andy Sifferman1 said:
The DDR3 section containing the large buffer is marked "NOLOAD" in the linker script, so nothing is loaded into the DDR3 buffer during this step.

What if you remove "NOLOAD"? Do you see the same behavior?

Andy Sifferman1 said:
Further experimentation has shown that the same behavior occurs within the GEL script, too.

Which GEL script did you run?

Regards,

Jianzhong

0 Andy Sifferman1 over 4 years ago

Prodigy 200 points

Hi Jianzhong,

Jianzhong Xu said:
What if you remove "NOLOAD"? Do you see the same behavior?

Yes. Removing NOLOAD causes the .out file to include a 16MByte buffer filled with zeros, which is loaded to DDR3 starting at 0x80000000 after the GEL script has finished running. This takes some time. If the first bytes of the buffer were previously changed by the GEL file, then they will be overwritten with the zero data too. But this doesn't prevent the later overwriting of the data again in Board_DDR3Init() when the firmware is executed.

Jianzhong Xu said:
Which GEL script did you run?

Andy Sifferman1 said:
evmk2g_arm.gel

As I've thought about this behavior, it has occurred to me that function Board_DDR3Init() does its job by writing to the EMIF registers, which will possibly cause a momentary reconfiguring, or reset, of the DDR3 refresh timing. I don't know how long this takes (i.e. whether it is longer or shorter than a refresh interval), so I don't know whether other DDR3 memory is affected. But perhaps it is during this process of changing DDR3 timing that part of DDR3 memory is overwritten.

So perhaps the question really is, Can we count on any DDR3 memory containing valid data after calling Board_DDR3Init() ?

0 Jianzhong Xu over 4 years ago in reply to Andy Sifferman1

TI__Guru 62240 points

Andy,

I experimented this on my K2G EVM and didn't see this behavior. DDR memory was not changed by Board_DDR3Init(). Since you are using a custom board, there may be a need to modify and rebuild the board lib.

The GEL script you mentioned should be running when you connect the ARM core in CCS. Did you mean the DDR memory was filled with those patterns when the ARM core was connected? Or did you manually run any GEL script after connection?

Regards,

Jianzhong

0 Andy Sifferman1 over 4 years ago in reply to Jianzhong Xu

Prodigy 200 points

Hi Jianzhong,

Jianzhong Xu said:
Since you are using a custom board, there may be a need to modify and rebuild the board lib.

I have already created a modified version of the board library. The modifications set the RAM size to 512MB, and add a new and different NOR flash device. Otherwise, I have made no other changes to the board library. What modifications do you think I may need to make?

Jianzhong Xu said:
Did you mean the DDR memory was filled with those patterns when the ARM core was connected? Or did you manually run any GEL script after connection?

After the evmk2g_arm.gel script completes execution, the program is loaded into target memory. When the load is complete, the debugger is halted with the PC at main(). The patterns are seen in memory at this time.

I did not run any other GEL script.

Andy

0 Jianzhong Xu over 4 years ago in reply to Andy Sifferman1

TI__Guru 62240 points

Andy Sifferman1 said:
After the evmk2g_arm.gel script completes execution, the program is loaded into target memory. When the load is complete, the debugger is halted with the PC at main(). The patterns are seen in memory at this time.

Can you check how the DDR memory look like after connection but before loading the program?

0 Andy Sifferman1 over 4 years ago in reply to Jianzhong Xu

Prodigy 200 points

Jianzhong Xu said:
Can you check how the DDR memory look like after connection but before loading the program?

This depends on the previous state of the device.

If the device has never been powered up, then the EMIF controller has never been initialized, and the DDR memory is not visible in the debugger's Memory Browser.
- After the evmk2g_arm.gel script runs, the EMIF controller will now be running, and DDR is now visible. The contents of the memory will be random, or a corrupted version of an earlier state.
If the device was previously running, then the EMIF controller might be still refreshing the DDR memory. In this case, the DDR memory will contain the contents of the previous execution of the firmware.

0 Jianzhong Xu over 4 years ago in reply to Andy Sifferman1

TI__Guru 62240 points

Andy Sifferman1 said:
After the evmk2g_arm.gel script runs, the EMIF controller will now be running, and DDR is now visible. The contents of the memory will be random, or a corrupted version of an earlier state

This is expected. That's what I saw on my EVM.

Andy Sifferman1 said:
If the device was previously running, then the EMIF controller might be still refreshing the DDR memory. In this case, the DDR memory will contain the contents of the previous execution of the firmware

This is also expected.

I still don't see any reason why DDR would be filled by Board_DDR3Init() with those specific patterns you mentioned earlier.

Processors

Processors forum

66AK2G12: DDR3 initialization overwrites first bytes of RAM