• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 561 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.

Error on malloc() function for OMAP-L137 DSP

Eugene C
Prodigy 190 points

Hi,

  I am using OMAP_L137 DSP non-BIOS. There is a 16-bit DDR RAM connecting to the EMIF_B port.

  I need create a big float array (4096 entries) using the malloc() function below. However, it reports memory allocation error. If I reduce the size of the array from 4096 to 256, then everything is fine.

  My first question is what's wrong of the code? Is it because of the limited internal RAM? how to solve this bug.

  My second question is I want to use the external DDR RAM for the dynamic memory allocation with malloc() function. In the DSP code, how can I achieve this target? Thank you.


/////////////////////////////////////////////////////////

　    My_array  = (float*) malloc (4096 * sizeof(float));

    if (My_array  == NULL)
    {
        fputs ("My_array  Memory error\n",stderr);
        exit (2);
    }
/////////////////////////////////////////////////////////

  • 0
    TI__Genius 17355 points

    When you are not using Bios (or any OS), your code will be using the standard C libraries that come with the compiler (known as the run-time support libraries).  The malloc/free dynamic memory routines will allocate and free from the heap, which is the memory in the .sysmem section of your application's memory map.  The size of this section will be determined by the -heap option that you give to the linker (I think the default is 0x1000 = 4KB, which might explain the allocation issue you saw).  If you want to relocate the .sysmem section to another location in memory, then you simply need to modify the linker command file to place that section at a different location in the memory map.

    All of the details on how to do this can be found in the C6000 Assembly Language Tools User's Guide (go here to get the appropriate link depending on which version of the code generation tools you are using).

    Regards, Daniel

  • 0
    Prodigy 190 points

    Hi, Daniel,

      Thank you for your reply and your information. You are correct. The bug is due to the heap size. After increasing the heap size, the 1024 entries array can be created when I use internal RAM as sysmem.

       However, when I modified the .sysmem to be using external SDRAM, the printf() function does not work normally, with the same code to generate the float array. I use the printf() function to print out the elements in the array to verify. But the printf() can only display the first character. Without this, I cannot confirm whether the generated float array is correctly or not. May I know how to solve this bug when using external SDRAM as sysmem? Thank you.

     

      

  • 0 in reply to Eugene C
    TI__Genius 17355 points

    Not sure what could be causing this, and I've never seen this type of error myself.  You might want to try and follow the tips listed over here:

    http://processors.wiki.ti.com/index.php/Tips_for_using_printf

    Some of that may help.  The only other suggestion I might have is to manually try and step through the code, doing things like step-over printf calls and see if they work as expected.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Prodigy 190 points

    Hi,

      After reading through the tips on your link, I still cannot find what's wrong of the code. I used assembly step over. For both scenarios, the steps are the same. However, the printf() function when using the external SDRAM as .sysmem still displays only the first character.

      Would you suggest which TI E2E forum group I should ask for?

      In our PCB, the external SDRAM is 16-bit data bus width, instead of 32-bit. Do you think it may bring this bug? Thank you.

     

  • 0 in reply to Eugene C
    TI__Genius 17355 points

    If you are still having issues with this, I would suggest placing breakpoints on the readmsg and writemsg routines.  These are the lowest level routines for the CIO operations and you should be able to inspect the CIO buffer to verify its contents.  If the formatted string from a printf statement makes its way into the CIO buffer correctly, but still doesn't display in CCS, then chances are the issue is on the host side under CCS.  I can't say what the problem would be exactly, but at least you could eliminate the target and its software as a problem.

    Regards, Daniel