Custoam board resets in C_int00

James Thorton said:

Before the program reaches main() the CCS shows that a target reset have happened.

Does this mean that you are getting some error message/box from CCS or that the program counter is simply always at c_int00?

The c_int00 function is just the first function (i.e. the reset vector points here) in a C program that initializes the C environment so it makes sense that you would get there after a reset event. If you step through the c_int00 assembly how far will it go? I am curious if it is resetting at the same instruction every time or if the reset is more random.

In general since this looks like the same binary will work on the EVM but not on the custom board, this may be a hardware issue, you can see strange operation like this if the device is out of spec, and in particular if the code gets corrupted somehow. This being said I would start by verifying voltages and clocks on the custom board, and verifying that the memory you are loading the code to is fully functional and stable. You may also want to check any of the reserved pins on the device to ensure that your custom board is not inadvertently putting the device in a invalid state.

Bernie Thompson said:

Does this mean that you are getting some error message/box from CCS or that the program counter is simply always at c_int00?

Yes, we were receiving a message box (the box has the same format as when you connect/disconnect the EVM) warning us about a target reset. This happened this morning, right now there isn'r any reset, but we are not still able to enter main(). We have checked that DDR2 was filled exactly as it is filled when we use the EVM. So it means that we can access and write the DDR without problems.

Besides we have managed to enter the main() a couple of times by executing the program step by step (we have tried more times but it was not possible to reach the main() again), so we think that it fails randomly. Take in account that we are using dm6435 in our custom board instead of dm6437.

Thanks a lot

Bernie Thompson said:

This being said I would start by verifying voltages and clocks on the custom board, and verifying that the memory you are loading the code to is fully functional and stable. You may also want to check any of the reserved pins on the device to ensure that your custom board is not inadvertently putting the device in a invalid state.

I just want to add that we passed a TI ddr test project succesfully in our custom board. Moreover, the program works without any problem if we allocate all sections in internal RAM/cache.

            An update about the problem: finally we have been able to run the whole program, allocating everything in internal ram but .text that was allocated in DDR.

Hi again, this is the linker configuration that we are using:

    .bss        >   DDR2
    .cinit      >   DDR2
    .cio        >   DDR2
    .const      >   DDR2
    .data       >   DDR2
    .far        >   L2RAM
    .stack      >   L2RAM
    .switch     >   DDR2
    .sysmem     >   L2RAM
    my_sect    >   DDR2
    .text       >   DDR2

By the time we try to change any section allocated as L2RAM to DDR2, the program stops working. So it means that the critical sections are:

.far
.stack
.sysmem

This is in a HelloWorld project not based in DSP/BIOS. Why couldn't these sections be in DDR2?

James Thorton said:

Why couldn't these sections be in DDR2?

This is a good question, these are all data sections which are uninitialized, however since you can have .bss in DDR2 that indicates that you can have a data section that is unitialized in external memory (assuming .bss is not empty for your project) which makes the similarities between the sections you have problems with less obvious. If we leave out the .bss section for the moment than it would seem that there may be some problem with your program writing to DDR2, since this would mean that only initialized sections are in external memory. Though it is quite strange that the emulator is able to write to it and that the DDR2 tests pass so this does not make sense unless your project is doing something special, like reconfiguring the DDR2 interface, which does not make sense either because you mention that any project you run will have this problem.

Essentially I don't have any other good ideas based on the testing so far, the best I can suggest at the moment is to double check the schematic against the EVM and look for any out of place reserved or boot mode pins that might be leading to some weird device state that is generating these symptoms.

Hi Bernie, thanks a lot for your answer.

We have been checking differences between our custom board and EVM and we have seen that DDRVTPR value is 0x0000 001F in the custom board and 0x0000 0384 in EVM. We have checked too this value in two of our custom boards and the value is the same (0x1F)... may it mean something? We know that it is only a value to adjust and calibrate DDR... but as we have copied the routing of evmd DDR this should be quite similar. Anyway, we are using a different DDR (the equivalent to the one used in EVM, which is now obsolete) so finally it could be just that. Quite desperate right now.... :(

Ok, finally we have seen that definatelly there is something weird with our DDR. Take a look to this simple code:

#define size 32
#pragma DATA_SECTION(bufferB, "my_sect")  //In linker.cmd we got:     my_sect    >   DDR2
int bufferB[size]={1};

main()
{
int i=0;

while (i<size)
{
    bufferB[i]=1;    //WRITE ONE

    if (bufferB[i]!=1)   //CAN'T READ ONE?
        {
        printf("\nERROR A!! %i\n", bufferB[i]);
            if (bufferB[i]!=1)  //CAN'T READ ONE?.. SHOW ME IF WRONG VALUE HAS CHANGED
            {
            printf("\nERROR B!! %i\n", bufferB[i]);
            }
        }
    i++;
}

We obtain the next output:

ERROR A!! -847917355

ERROR B!! -10099204

ERROR A!! -847917355

ERROR B!! -540719796

ERROR A!! -1804801085

        So it seems that there is some problems writting and/or reading in DDR, moreover, it seems that values in ddr are not stable as you can see values in error A and B are different. This same example we have tried in EVM and works with no error.

       But we tried ddr test project from TI, and our board passed without problems. I have added some code of this project to mine, and although once or twices give some error, now I have passed succesfully. This was the code that I have used:

   //WRITE pattern:

    for ( i = 0x80000000; i < 0x81000000; i += 4 )  
    {
        *( volatile int* )i = 1;
    }

    /* Read Pattern */

    for ( i = 0x80000000; i < 0x81000000; i += 4 )
    {
        if ( *( volatile int* )i != 1 )
        {
            printf("\nERROR C!!\n");
        }
    }

And as I say, in other tests it gives me some error (just in one or two directions) worked well this time.

The main difference between my "testDDR" and TI test, is that TI test uses only pointers to write/read over DDR and allocate all the sections in internal RAM. I don't use pointer, I declared a vector (bufferB) over section in DDR, and I writte/read this vector, which means that I am writting DDR.

Why may my test fall? why TI test are working and mine not in our custom board? Both work perfect in EVM.

So... could all this issue give some clue about what to look for??

Thanks in advance for any help

PS: we have tried several zones in our DDR and all seems to have the same weird behaviour.

James,

I do not have a good idea of what could be happening.

Please check if when you are connecting to the EVM you using a GEL file and if when you are connecting to your board you are not using a GEL file. The GEL file initializations could be missing ... 

we have built a gel file for our custom board (we took evmdm6437.gel and remove the main part, we just leaved ddr configuration; we tried evmdm6437 too ). We tried this new gel file with our projects (helloWorld) and does not work in our custom board but it does in evmdm6437. Moreover we changed some parameter to adjust ddr configuration to our new memory (for example CAS latency changed from 4 to 5 in our new DDR ram), but again the same thing: does not work with our custom board but STILL with evmdm6437, although as I say we changed some parameters to adapt to new ddr. :( Any more advices?

do you drive the DDR2 when your custom board is on power?

          I don't understan well you question Jason. What do you mean exactly? Of course the board is on power when we tried the program, but I don't think you refer to that exactly...

my msn:jason_685@msn.com, could I get touch with you by msn or other chat tools? So we can talk about the problem conveniently, I have the same difficulty as yours.

I can run the programme which isn't based on DSP/BIOS on my first custom board.

James can you email me? I'd like to know what memory test you are running and possibly take a look at your board layout. Thanks

Jeff

James,

Would you mind sharing what changes you made? Was it a timing issue or something else?

Good news. I would still like to see the TI DDR2 test code you used which failed to detect the errors you saw. If the code you wrote detected the errors but this code did not, we will want to fix the TI code. Let me know,

Jeff

James,

Could you post what you changed in the initialization to get it working.

We have exactly the same problem and trying to get DDR2 working as well.

Thanks,

Vadym

Vadym,

Take a look at your SDTIMR register value and try tweaking it to see if this helps. The values in this register should match those found in the memory's datasheet.