• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 97 subscribers
  • Views 574 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problems with porting project to DSP/BIOS

John Kofod
Prodigy 200 points

I'm porting my working project to DSP/BIOS and it's resulting in some strange behavior.
When I write values to a large array, which I've placed in my extern memory DDR2, and afterwards view them in
the memory map, I can see that they are shattered and wrongly placed with zeros and random numbers in between.

Test case:

#pragma DATA_SECTION(arrayX, ".ddr2")    //Linked to DDR2
#pragma DATA_ALIGN(arrayX, 8)
unsigned char arrayX[500];

#pragma DATA_SECTION(arrayY, ".ddr2")    //Linked to DDR2
#pragma DATA_ALIGN(arrayY, 8)
unsigned char arrayY[500];

...
    memset(arrayX, 0, 500);
    memset(arrayY, 0, 500);

    for (i = 0; i < (500); i++)
        arrayX[i] = 50;

    for (i = 0; i < (500); i++)
        arrayY[i] = arrayX[i];
...

Results in totally wrong arrays. The end of arrayX got some zeros in between the inserted 50-values.
And arrayY is messed up with 50-values at the first 12 indexes then zeros for the rest with random numbers in between.
At first I was suspecting the build options for the compiler, but the problem remains with no optimization.

Is there something obvious I'm missing here?

My heap and stack are huge, so that's not the problem.

Using CCS 3.3 with BIOS 5.31 on a DM6437 EVM.

  • 0
    TI__Guru*** 125430 points

    Try disabling interrupts around that code to make sure something else is not coming along and corrupting the values.  There must be something really fundamental to cause this issue.  For example, how are you configuring the DDR2?  With the gel file?  Make sure you're not doing it from inside your code as that can cause odd behavior to reconfigure the DDR interface while data is already present in the DDR!

  • 0 in reply to Brad Griffis
    Prodigy 200 points

    Have tried putting the code in a disable interrupt block:

    oldInt = _disable_interrupts();
        //Code...
    _restore_interrupts(oldInt);

    Without any luck, same problem.

    I have narrowed the problem down, since I've tested that everything works as it should, if I
    put the two arrays in intern memory (removing '#pragma DATA_SECTION()' from above code).
    Thereby it could have something to do with the initialization of the DDR2, as you also mentioned.
    I'm using the same gel file as I was in the working non-BIOS project. And I've tried every
    configuration in the tcf. Am I suppose to do something with the gel when I go from non-BIOS to BIOS?
    I'm not touching the DDR2 configuration "inside" my code.

    Thanks

  • 0 in reply to John Kofod
    TI__Guru*** 125430 points

    Can you put the arrays in DDR2 in your non-BIOS project?  This is really bizarre.

    Can you try something like this:

    oldInt = _disable_interrupts();

        for (i = 0; i < (500); i++)
            arrayX[i] = i;

        for (i = 0; i < (500); i++)
            arrayY[i] = arrayX[i];

    _restore_interrupts(oldInt);

    Set a breakpoint at the restore_interrupts line (i.e. halt before breakpoints are restored) and please post the resulting output.  I'd like to see precisely how it's being corrupted.

  • 0 in reply to Brad Griffis
    Prodigy 200 points

    Jesus. Stupid mistake. I was refering the initialization of the board to my old modified version.
    After including and linking to the right init (EVMDM6437_init();), it of course all worked as it should.

    Please delete this whole post, since it's retarded of me.

    But thanks anyway Brad...

  • 0 in reply to John Kofod
    TI__Guru*** 125430 points

    John,

    Thanks for reporting back the cause of the problem.  Nothing to be embarrassed about -- happens all the time!  I'm sure this will actually end up helping more people than you might expect.

    By the way, note that the function EVMDM6437_init() actually has code in there to initialize the DDR2.  Personally I think that's a bad thing to do since it's very common to have code or initialized data residing in DDR2 in which case you can corrupt it or totally clobber it by reinitializing the DDR2.  The PLL initialization and DDR2 initialization should all happen in the gel file.  When you move to production that responsibility should shift to the bootloader (i.e. AIS or your own secondary bootloader).

    Brad