C6670 DDR configuration table location overlap problem

So the DDR_CFG address is in the L2SRAM region. But when I placed the DR_CFG address like in the C6657 0x8ffd20 the project build just fine. What causing this problem? Since DDR3 and L2SRAM was defined by the platform wizard and I specify the correct DDR_CFG address from the data manual it should work correctly. Or the platform wizard have occupied the space in the L2SRAM supposed to be for DDR_CFG?

Hi Raja,

Thank you for your fast answer. But things that you say makes me more confusing somehow. I can explain why. So while I was looking the solution of my problem at Forum I have find this topic

.

Please look at the bottom part of Rahul Prabhu verified answer. "Memory map for placing the DDR configuration table is different between the 2 devices so you will have to chnage the location of DDR_CFG to 0x00873500 instead of 0x8ffd20 in the .cmd file."

Also I think in this topic  the same person Rahul Prabhu said that "Hence information on Parameter table, DEVSTAT registers, DDR configuration table is provided in the datasheet for the device rather than the bootloader user guide. I found that this information is missing in the C6670 documentation but is available in the C6678 documentation."

But the problem is when I tried to specify the address you suggested I get this hardware error: "C66xx_0: File Loader: Verification failed: Values at address 0x000000008430D420 do not match Please verify target memory and memory map. "

UPD: I have solved the error that occurs, seems to be that it was connected to the System heap relocation to the DDR3. But the reason for that is that DDR3 wasn't initialized by the Boot loader. If I put .text or to the DDR3 section after loading the program to the device it's just hang and code doesn't executed. 

Best Regards,

Pavlo!

Hi Pavlo,

You can refer "Table 2-3 Bootloader section in L2 SRAM" from C6678 Data manual for RBL strorage on L2 however the start address is 0x8FXXXX for C6657/70 devices.

Thank you.

Hi Raja,

I have tried to do as you suggested. SO I have taken next values: DDR_CFG   :  origin = 0x8f3500, length = 0x100. So the DDR_CFG and L2MAGIC regions are created correctly since the application is building and loading to the device. And then I'am booting the code from MSMCSRAM like it was before there aro no problems. But when I try to put the .text section to the DDR3 (this is why I'am doing all of this) the DSP just running with no operation performed. Like no code was ever passed. But I have successfully moved to the DDR3 .stack and .const. 

I have checked the addresses of DDR_CFG  through CCS memory browser. And not all of the memory cells are populated with 0 at the startup (In Debug mod after System reset before we hit the resume button). Is it correct?

Do you have any ideas what could be wrong with my booting setup? I don't know is it worth to mention that the DDR3 is also initialized in main with platform_init() API.

Best Regards,

Pavlo!

Hi all,

So I made some more tests and tried to load the boot tale through the Ethernet. The booting is successful but after booting is complete DSP hang at the _c_int00, which is to my knowledge is application starting point. I would be appreciated for any ideas or hints what causing that problem and how to solve it, because I'am kind of stuck here. 

Also when I'am starting  device with .text section placed in the DDR3 (Program.sectMap[".text"] = "MSMCSRAM";) in .cfg file or in the .cmd file (.text  > DDR3) or both of them always pops up this error

C66xx_0: File Loader: Verification failed: Values at address 0x0000000084245420 do not match Please verify target memory and memory map.
C66xx_0: GEL: File: F:\Proj\mtp300_unch\src\pjts\dsp\Debug\mtp300_dsp.out: a data verification error occurred, file load failed.

If I place the .text to the MSMCSRAM launch one time the problem disappear (there was no such problem before the .text section moving). And after this if I place the .text to the DDR3 no error occurred, until the next launch.

Best regards,

Pavlo!

Pavlo,

Sorry to know that you are facing these issue with setting up your application to boot from DDR. A word of caution, the DDR initialization sequence for C667x underwent some changes since the ROM bootloader (RBL)code was last released for this device so the the code for initializing the DDR in the RBL doesn`t comply with the DDR User guide. It is our recommendation that for placing code in DDR, you should use a secondary bootloader as we have demonstarted on the EVM using the IBL. The first stage of your code will load into MSMC and then initialize code in DDR using platform_init and then proceed to load code from the boot media into DDR. ALso, note the RBL also doesn`t support DDR leveling on C6678/C6670.

In the past some users have been able to get the DDR to initialize at slower speeds from the RBL without requiring DDR leveling and then placed code into DDR memory and have increased the DDR speed and applied the leveling parameters as part of platform_init from their application code.Inorder to this, they had to test the DDR timing values through a GEL script before using them from the DDR configuration table.Can you let us know if you have tested the values you used in the DDR configuration table by using it in a GEL file to see if they work to initialize the DDR. Are you seeing this issue on the EVM or your custom hardware?

Regards,

Rahul

Rahul,

Thank you very much for your reply on that post. I'am working with custom device and our code wouldn't run on the EVM, so unfortunately the GEL file testing is not an option for me.

Here what I have discovered since my last post:

1) To initialize correctly DDR3 we can use a platform_init() routine passing to it platform_init_flags structure with ddr filed raised to 1. In our application we already using DDR3 for storage of large amount of data. So for testing my code running from DDR3 I have found some workaround. First I launch the application with .text placed in the MSMC and pass the init_flags.ddr = 1; So the DDR3 gets initialized. Then I'am breaking the application, change the location of .text to DDR3 section, and change init_flags.ddr = 0; then rebuild and working from DDR3. Everything working just fine. If we don't pass the 0 in ddr field to the platform_init() it will re-initialize the DDR PLL and our application will be erased from DDR3. That is the problem I was having with application hang at _c_int00. All this action I have performed through emulator

2) We have our custom boot loader that waiting for BOOTP and then sending the text from host binary .ini file (prepared according to all rules from .out) to the  DSP and perform the booting. So now I want to create 2 .ini files (boot tables) and do as you say send the first one with .text placed in the MSMC and ddr flag set to one, and the send second table with .text placed to DDR3 and ddr flag is 0. As I have done with emulator. But now I have the problem since after first .ini file DSP stops generating a BOOTP signal, which is standard case. So the main question how to make it generate the BOOTP second time or  how to boot both images with one run?

I have tried the routine from SRIO boot

#define MAGIC_ADDR 0x8ffffc

#define BOOT_MAGIC_ADDR(x) (MAGIC_ADDR + (1<<28) + (x<<24))

main

{

void (*exit)();

uint32_t entry_addr;

/* Clear the boot entry address of the boot image and start to boot */
DEVICE_REG32_W(BOOT_MAGIC_ADDR(0), 0);

entry_addr = DEVICE_REG32_R(BOOT_MAGIC_ADDR(0));
if (entry_addr != 0)
{
/* jump to the exit point, which will be the entry point for the full IBL */
exit = (void (*)())entry_addr;
(*exit)();
}

    BIOS_start ();

}

but I get an fetch error, so my application override with some reserved memory location as I understand. One thing to mention I made this steps before   BIOS_start (); if it matters.  

Best Regards,

Pavlo!

Rahul,

I have tested the GEL file and managed initialize the DDR3. I took the standard evmc6670l.gel from the MSDK folders. But in this case I didn't use a boot table for DDR3 initialization. Actually if I use only boot table as I described in the beginning of the topic the DDR3 didn't work at all. 

Best Regards,

Pavlo!

Can you please post the GEL file and the DDR configuration structure that you have used so that I can check for any issues. What is the DDR speed you are trying to achieve. Have you tried to initialize it at lower DDR speeds?

Regards,

Rahul

Hello Rahul,

Thank you for following the problem.

I have add the GEL file please find it attached to this post. As you can see from the file I'am using PLLM_DDR = 19 and PLLD_DDR = 0 for 1333 MHz. In this way DDR3 seems to initialize properly and program working just fine. I didn't try lover frequencies since the higher one is working correctly.

7242.mtp300.gel

Also I have some questions about 2 stage bootloader. A have found some exampleof simple 2 stage bootloader but when I try to apply them to my code I get the  unresolved symbol romtReInit, first referenced in ./mtp300_dsp.obj mtp300_dsp C/C++ Problem . So the problem in the romtReInit (); which defined as void romtReInit(); and described in the .cmd file as Rom re-entry function _romtReInit = 0x20b00008;.  I saw some your post about that strings to the other guys but I can't even compile that kind of code.

Also I'am really confused about IBL. Do we need to flash our first stage booting program to the EEPROM or it's written to the first 128KB of L2SRAM or this place we can choose?

Best regards,

Pavlo!