• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 267 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

TMS320F28379D: error #10099-D: program will not fit into available memory

TMS320F28379D: error #10099-D: program will not fit into available memory

Fred Schreiber
Prodigy 110 points
Part Number: TMS320F28379D

(This is a follow-on to a question sent in July regarding linker error 10099-D; and answered by Trey German8. I hope he is still available.)

Hello Trey,

This problem was put aside for a while but has come back to the surface. I reviewed your initial response, and I did take a look at the .cmd file, and also the .map files for successful and failed builds. I also looked thru the linker command "Primer" link that you sent. But I'm still a bit new to this environment.

I can see in the failed map file where the error occurred (setting up .cinit for global variables initialization). But I don't know how to resolve it. I'm going to try and drag the .cmd and the two map files (good and bad) into this edit window. I'm hoping this is a 2 minute fix for someone who's been around the block. But if there is more digging for me to do, please point me in the right direction.

  • 0
    TI__Mastermind 30185 points

    Hello Fred,

    Trey does not work for TI and so this thread is not assigned to him, if you want to directly contact him I believe you can send a friend request and privately message him. I will try to answer your question here in the meantime.

    Fred Schreiber said:
    I'm going to try and drag the .cmd and the two map files (good and bad) into this edit window.

    One way you can find more about this error is by double-clicking it in the Problems window; this should open the linker command file directly to the section which is full and needs more memory. Additionally, you can check this with the Memory Allocation window to see which memory units are full:

    This error from my experience only occurs in the linker command file (.cmd) that is in the project, and is easily fixed by adding more memory to the section.

  • 0 in reply to Omer Amir
    Prodigy 110 points

    Hello Omer,

    Thank you for the quick response. I followed your advice (and your friend Trey's), and some educated guesswork, and edited my .cmd file with the intent to clear the .cinit line error. The next build was successful, which was of course the goal. But while I trust your advice, my guesswork could be clever, or maybe just lucky. So I'd like to run my changes past you on the chance you'll recognize any risky behavior.

    The original cmd file had this under SECTIONS (FYI the MEMORY section allocates FLASHA thru FLASHN, each with 8192 bytes) :

    /* Allocate program areas: */ the .text line as is.
    .cinit : > FLASHB     PAGE = 0, ALIGN(4)
    .init_array : > FLASHB,      PAGE = 0, ALIGN(4)
    .text : >> FLASHB|FLASHC|FLASHD|FLASHE    PAGE = 0, ALIGN(4)

    In order to give more space to .cinit, I changed it as follows:

    /* Allocate program areas: */
    .cinit : > FLASHB|FLASHC PAGE = 0, ALIGN(4)
    .init_array : > FLASHC, PAGE = 0, ALIGN(4)
    .text : >> FLASHB|FLASHC|FLASHD|FLASHE PAGE = 0, ALIGN(4)

    I changed init_array to FLASHC (educated guess) because I assumed FLASHB was getting filled.

    I did not touch the .text line because the description in the "Primer" link (from Trey) says this syntax tells the linker to use FLASHB, and if B is full use C, and so on. My memory allocation window shows FLASHE not being allocated at all, so I figured the linker would have room re-allocate as needed.

    Can you confirm my changes made sense? Or did I do something that can blow up on me later?

  • 0 in reply to Fred Schreiber
    TI__Mastermind 30185 points

    Hello Fred,

    I personally recommend using a Flash that is not used elsewhere; while the Flash banks are sizable, in the case that your program does happen to run out of space past Flash C (the .text section), then there might be an issue. You have plenty of Flash banks, so this should be okay (unless you plan to use them some other way).