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.

2-Dimensional array in extended memory



I have a 2-dimensional array "x[ ][ ]" which I want to locate in extended memory (an external SRAM). I believe there is a Linker directive so I can set the base address to the base of the external SRAM "0x6000 0000". Note that I still want to use the internal SRAM (256KB) in addition to the external SRAM(1MB).  I am using the TM4C1294. 

If there is is a method without a linker directive, I would be interested as well.

Thank you.

  • Hello Joseph,

    You can do that. However the EPI and it's IO which interfaces to the SRAM is not configured at reset. Hence the bss initialization shall fail with a Bus Fault. Once the code initializes you can assign a pointer to the memory address. This way the compiler will not try to initialize a memory region that has not been enabled.

    Regards
    Amit
  • Or set up the memory before the startup initialization is called. This is the more conventional approach and it lends itself to a more natural usage of memory.

    Initializing after startup initialization works well for memory used as heap or I/O.

    Robert
  • Thanks both to Amit & Robert especially (and to probing poster) - good stuff!

    I assume, "post startup initialization of external memory" suggests that - if done carefully/properly (i.e. prohibit all new accesses during the reconfig.) we may alter that initialization dynamically (i.e. change the initialization) - based upon program requirements. (then re-enable access)

    This "reconfigure on the fly" was long a key feature of FPGAs - appears of use here, as well.

    Might you comment? Merci.

  • Hello Robert

    Are you suggesting using the GEL to set up the memory before download?

    Regards
    Amit
  • I have no idea what GEL is Amit.

    Every microcontroller I've used that has had an external memory, I've setup the memory before the startup initialization of memory.

    It's not a big handicap, the setup can even be done in C in many cases as long as you remember it's not a standard environment. In cases where the only on-board RAM is the processor registers assembly is usually required since there is not way to configure a stack but for processors with a generous memory (and the TIVA processors certainly qualify) you can setup the stack and call a few routines to do the setup. The routines just cannot depend on normal initialization being complete. As long as they only use automatic variables they should work fine. Once the memory is setup the initialization proceeds to the normal initialization and sets up the C environment, setting memory values and the usual run time stack.

    Robert
  • cb1- said:
    I assume, "post startup initialization of external memory" suggest that - if done carefully/properly (i.e. prohibit all new accesses during the reconfig.) we may alter that initialization dynamically (i.e. change the initialization) - based upon program requirements. (then re-enable access)

    I suppose you could. For memory it seems unlikely that the config would change much for an embedded system after startup.  Even with I/O I'm having trouble envisioning when that would be helpful. Possible to do so though.

    Robert

  • Robert Adsett said:
    having trouble envisioning when that would be helpful.

    Consider a 16 bit (5-6-5) color TFT - w/memory configured for that color depth - for "normal" display use.

    Yet - when our desire is to speed display access (i.e. to graph a key result - achieved via reduction in the number of color bits) - such reconfig. proves useful...

  • Got it.

    Then, yes, if the memory subsystem was flexible enough you could reconfigure on the fly. That's really I/O rather than memory but it's a grey area.

    Robert
  • Hi Amit,

    I perform an EPI initialization, using the ROM instructions, to include the external RAM as an HB8. With all my data predefined the compiler will give me an error since it is larger than the internal SRAM. I am using the IAR Embedded Workbench and tried modifying the .sct Linker Configuration file to no avail.
  • Hello Joseph,

    OK. Let me give you the CCS perspective (and in continuation of what Robert mentioned). Before the c_init00 routine is called, i would perform initialization of EPI controller so that RAM region is accessible.

    In IAR it would be done by __iar_program_start. So before this all of the init must be done.

    Regards
    Amit
  • Joseph Curasi said:
    ... using IAR Embedded Workbench...tried modifying the .sct Linker Configuration file...to no avail.

    Our group uses IAR - usually the .icf file proves more suitable.    Inserted is a search result from w/in IAR's doc. package - we found "no match" to .sct.

    Note that there is a suggested "safe/best" method to edit that .icf file - again explained w/in IAR's docs.

  • Thank you cb1-

    In the .icf file I defined a second SRAM region, and then placed "EXTENDED_DATA" in SRAM2. I then referenced it from my C code with:

    #pragma default_variable_attributes = @ "EXTENDED_DATA"

    X[M][N]

    #pragma default_variable_attributes = // must leave blank to terminate region

    Thank you to all that have contributed.

    Joe

  • Thank you too, Sir. Glad to have helped - your IAR will prove so much more suitable than vendor's (still) SWD-less, single source restricted, blind to automated cycle count, incarnation... (free - not always best - especially when a, "straight-jacket" is included/enforced!)
  • "automated cycle count" cb1? I don't recognize that phrase in this context.

    Robert
  • I've not got IAR open/connected at the moment - yet you'll find many here - (unwisely) locking themselves into single source - and thus having to resort to all kinds of "extra effort" to yield features/capabilities long "built-in" to "pro" IDEs such as IAR/Keil.    Automated cycle count is just one illustration - there are many.  If you wish - and when again IAR is up/running - I can post screen cap.

    All too often - one gets (and deserves) what one pays for...

  • Maybe so but what is it? As I said I don't recognize the phrase in the context of a compiler.

    Robert
  • Sorry - I didn't read your question in that way.

    Automated cycle count is one entry in one of IAR's System Control Register Display - usable when the J-Link is connected to a powered, running MCU. (mine is not easily brought up - now) As I recall there are 3 such count trackings - shown are, "Total Cycles used to this point" (perhaps a break point) another is, "Cycles used for the most recent "Program Step"" the 3rd (I know there are 3) escapes me.

    These are all fully automated - require no user set-up nor special - add on programming. Vast majority here wind up, "Using free" - I wanted to encourage the use of those IDEs which provide users here "real choice" beyond red-branded "lock-in."
  • Thank you Amit,

    I performed initialization as you specified to avoid a fault error.

    Joe
  • cb1- said:
    Sorry - I didn't read your question in that way.

    Not a problem, cycle counting got stuck in my brain as an inventory technique.

    cb1- said:
    As I recall there are 3 such count trackings - shown are, "Total Cycles used to this point"

    Aha! instruction timing.  We use IAR here, I've never used that feature.

    Robert