• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 2195 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.

DDR memory's allocation

long gao
Intellectual 770 points
Other Parts Discussed in Thread: OMAPL138

 Before i changed my array the "MEMORY CONFIGURATION" in my .map file is:"DDR:c0001000   cfffefff  06a29f51  c95d50ae  RWIX", this means i still have 147M ddr memory can use. but when i enlarge it & the left DDR is67M, which i think still reasonable, but when i download to the Hw it run immidately. My DDR

is 1G, so i can't understand why this happens?1817.Desktop.rar

     the accessory is the .cmd,.gel&.map files after i enlarge the array, please help me.

  • 0
    TI__Mastermind 43955 points
    Hi long gao,

    Can you please try this ?

    DDR2 o = 0xC0001000 l = 0x07800000 /* 120MB DDR2 */
  • 0 in reply to Shankari G
    Intellectual 770 points
    1. Yeah， i have change my .cmd as your suggestion. the compiler give out this error:"Description Resource Path Location Type
    #10099-D program will not fit into available memory. run placement with alignment fails for section ".far" size 0xbc40645 . Available memory ranges: C6748.cmd /Copy of svn line 80 C/C++ Problem"
    2. I set my properity in the "Data access model (--mem_modle:data) as "far" before, because if don't do this it will give out another error:"the symbol with a address 15bits can't fit to the address 16bits". this i think have some relations with the cpu's way of code dispach. so i changed it and it works. but i never assign the range of the .far item in my .cmd file. So i think it is still because of the lack of the memory.
    3. why should i reset the ddr to 120M?cause my chip is 1G & the c6748 can handle 256m?
    4. i think it's very wried, because in the .map after i enlarge my arrary(a big struct which include 30 arrays,i enlarged it to 60), it still have 67MB, i
    thought it will no problem. but it goes different with the ex-version. really confused me
  • 0 in reply to long gao
    TI__Mastermind 43955 points
    Hi long gao,
    Can you please try this too ?
    DDR2 o = 0xC0001000 l = 0x0FA00000 /* 250MiB DDR2 */

    If you able to build your project with this line, you can run the code without any problem, still if you face any build error, try to reduce the array and usage of RAM in your code.

    Yes, you can't use more than 256MiB DDR2 memory in C6748/OMAPL138.
  • 0 in reply to Shankari G
    Intellectual 770 points
    I have try this ,but it still go immidately when i download it .I need a array even bigger, i don't want to reduce it.So ,why the ccs running like this?
  • 0 in reply to Shankari G
    Intellectual 770 points

    Hi, Shankari G: please help me...

  • 0 in reply to long gao
    TI__Guru* 84110 points

    Long Gao,

    This is difficult to follow and to know what the many things are you have tried and that you have experienced.

    Please do a build using the 250MiB settings from Shankari:

    Shankari G said:
    DDR2 o = 0xC0001000 l = 0x0FA00000 /* 250MiB DDR2 */

    Set your array size to something that will fit in the available space so we can debug the problem with you. Once it builds successfully, attach the .map file from that build to your next post.

    long gao said:
    it still go immidately when i download it

    This statement is not clear to me. Please explain exactly what steps you take, and what you observe. Please include detail that would allow us to follow what you are doing and what you are seeing so we can help to debug the issue.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Intellectual 770 points

    1817.Desktop.rar

    OK

    1. in the 1817.Dsktop.rar is my setting in the .CMD;.gel&.map

    2."it go immidately" means: "after i download my .out to the board by my xds100v3, the "Resume(F8)", it go black immidately, which means the program runs automaticly.

    3.i have tryed the settings you give me but it sill work like the item 2

    4. my problem is: i have a big array names FPGA_DATA[30][1152000], use the setting in the 1817.Desktop.rar my program can work, means it won't go into the situation like item 2 discribed. but if i enlarge this array to FPGA_DATA[40][1152000] it will run like the item 2 says.

    So i think it maybe the reason of the memory is not enough, but after check the .map，it shows that i still have 67M memory, so i think it should not act like the item 2 says.

    I give you another project use the same .cmd。 in this project i defined a array a[x][1152000]; if i set the x under 50 my programe run regularly, but if i set it to 80 it will go immidately. but when it is 150, the data in the .map is  “  DDR2                  c0001000   0dffefff  0afcf0e3  0302ff1c  RWIXX”， it means i still have 0x0302ff1c, but it goes immidately, this is what i want to know.6765.test.rar

  • 0 in reply to long gao
    TI__Guru* 84110 points
    Have you checked the C compiler User Guide to see if there are limits on indexes of arrays?

    Do you define the array as a global or local variable? Is it initialized with any values?

    You could try allocating the array from the heap using malloc to see if that will affect the problem.

    To me, the best guess at a problem is in the initialization of global variables. The C runtime code will try to initialize some variables depending on how they are defined. All local variables are allocated from the stack, global variables are allocated from .bss or .far.

    When the program is running immediately after loading, it should be running from _c_int00 to main(), then stop at main() for you to begin controlling it. If you manually stop it using the Halt button, you can see where the program is executing. If it is not obvious to you what is being executed at that point, you can compare the address in the PC (Program Counter) to the values in the .map file to determine which runtime code is being executed.

    Stack overflow is a common problem that leads to unexpected results. If your PC is in non-program space or in code space it should not be in, stack overflow could be a reasonable thing to look at. Increase the stack size to the max possible or at least increase it a lot.

    Regards,
    RandyP
  • 0 in reply to long gao
    Guru 26430 points
    The symptoms would suggest that you have 128MB of memory configured. That is the size on the LCDK. You say that you have a custom board with 1GB DDR2. It is physically impossible to connect a 1GB DD2 to the C6748. Perhaps you are confusing 1 Gigabit with 1 Gigabyte. If you did manage to increase the size of your DDR, did you change the GEL script and AISGEN ini file to match?
  • 0 in reply to Norman Wong
    Intellectual 770 points
    My ddr‘s type is :K4T1G164QF, its 1Gigabit, it equals to 1024M. I think it still enough, much enough
  • 0 in reply to RandyP
    Intellectual 770 points
    Please check my 6765.test.rar, i define it before the main, so it is a global variables.
  • 0 in reply to long gao
    Guru 26430 points

    Not quite.
    8 bits = 1 byte
    1 Gigabit = 128Megabytes
    Check the K4T1G164QF datasheet. It has organization is 64Mx16 meaning 64MWords where each word is 16 bits. Convert to bytes and it is 128MB. Use this in your command file.
    EntryPoint o = 0xC0000000 l = 0x00000800 /* 2 KB */
    Vector o = 0xC0000800 l = 0x00000800 /* 2 KB */
    DDR2 o = 0xC0001000 l = 0x07FFF000 /* 124MB  = 128 -2 -2 */
    If you get a linker error, it will not run. If you can compile, it will likely run. Unless you run out of stack.

    EDIT: Correct my math.

  • 0 in reply to Norman Wong
    Intellectual 770 points
    Yes thank you very much , i give it a try.
  • 0 in reply to long gao
    Guru 26430 points
    From 6765.test.rar assumes 0xE000000 or 224MB of memory.
    0AFCF0E3 = Amount reported use in map file
    0AFC8000 = unsigned short a[80][1152000]
    -------
    000070E3 = stack and other variables used by library functions.

    Assuming 128MB of memory
    07FFF000 = 128MB -2KB -2KB
    000070E3 = stack and other variables used by library functions, from above
    --------
    07FF7F1D = space free for your big array
    07F71000 = unsigned short a[58][1152000]
    --------
    00086F1D = space free
    The theortical limit is 58 arrays of 1152000 shorts.
  • 0 in reply to Shankari G
    Intellectual 770 points
    Dear Shankari G:
    You have said that" you can't use more than 256MiB DDR2 memory in C6748/OMAPL138", but on the manual of c6748 on page 94 it said "DDR2/mDDR memory controller:
    – 16-bit DDR2 with up to 512-MB memory address space
    – 16-bit mDDR with up to 256-MB memory address space"
    which means the memory can be 512MB, were my comprehension wrong?
  • 0 in reply to long gao
    TI__Guru* 84005 points
    256 MB is the max supported on this device family as we are not aware of any memories that support 512 MB with the configuration that is available on this device.
    I don't see the page 94 reference in the latest data manual - are you sure you are looking at the latest rev of the data manual
    www.ti.com/.../tms320c6748.pdf