PROCESSOR-SDK-AM437X: DDR3 initialization in SBL

Oleg Osovitskiy

Part Number: PROCESSOR-SDK-AM437X
Other Parts Discussed in Thread: AM4377

Hello E2E Community,

I have a problem with DDR initialization from the bootloader on a custom board (AM4377 based). My RAM is DDR3 MT41K256M16TW-107 AAT from Micron.

I have working GEL files for my board and all the test applications are working fine when when loaded from CCS with these GEL files.

Now I have to boot the application from the bootloader (SBL). I take the existing one as a referrence point, put my custom timings and configs and I have a problem!

In GEL files I have this line:

#define DDR3_SDRAM_CONFIG 0x61A213B2 //16-bit DDR3

//this write initiates and EMIF initialization and also latches values to PHY

WR_MEM_32(EMIF_SDRAM_CONFIG,DDR3_SDRAM_CONFIG);

In my bootloader I reproduce this with this code:

    /* EMIF initialization and also latches values to PHY */
    regVal = pDdrEmifCfg->sdramCfg;
    HW_WR_REG32((SOC_EMIF_ADDRSP0_REG + EMIF_SDRAM_CONFIG), regVal);

But after that any write to SDRAM registers lead to the hang - the board is just stuck and not debuggable anymore.

If I comment this code out it goes further, my SDRAM is initialized, I can copy the application to RAM, I see that it is copied succesfully, but when I try to execute it - nothing happens.

My questions:

1. Is this step of EMIF initialization is realy important?

2. If after that the memory is readable/writibale - why the application in memory can't be executed?

3. How to debug after this point:

   /* Giving control to the application */
    pfnSBLAppEntry = (void (*)(void)) gSblEntryPoint;

    (*pfnSBLAppEntry)( );

I pass the control to application and... what? I'm writing this and I understand that I have to set the H/W breakpoint to address 0x80000000 and see what's going wrong there =)

I will give it a try tonight...

over 7 years ago

0 Rahul Prabhu over 7 years ago

TI__Guru** 116950 points

Oleg,

I have looped in the DDR expert to comment on the importance of writing to EMIF_SDRAM_CONFIG.but I would not recommend removing any code if it matches the GEL and TRM description of the EMIF initialization.

Can you confirm that you have the setup the debugging the SBL code where you are able to load symbols and step through the code:

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#software-debug-steps

Note: remove any GEL file that you may have as the GEL initialization can conflict with boot setup.

There may be multiple ways of debugging the passing of control to start application mechanism.

1. With the debug setup check to see if entry point is detected the same way as when you load using emulator. The entry point should match the symbol Entry in your application map file if your are using TI RTOS. If entry point is detected check to see if the code goes from ENtry into main. Before passing control to application, you can add symbols from application by Run-> Add Symbols and browsing to the application binary that you load using emulator. This load only the symbols without physically loading the binary. Check to see if the symbols align with the binary loaded by SBL.

2. Do you have a working boot binary on TI evaluation platform. If yes, then use that binary instead of your custom application binary to test the boot to make sure it works. Use something simple that matches between TI platform and your design like UART or GPIO example. This eliminates the boot image format and binary issues from being the root cause so we can focus on the DDR initialization. Another would be to see if you can load and run application from OCRAM instead of DDR.

Please let us know if either of the two approaches works.

Regards,

Rahul

Processors

Processors forum

PROCESSOR-SDK-AM437X: DDR3 initialization in SBL