• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 988 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.

TM4C123GH6PM: Tiva C Launchpad

Pranjal Shrivastava
Prodigy 210 points
Part Number: TM4C123GH6PM

Hello, 

I wish to copy my program image from the flash to the SRAM, and wish to execute it from SRAM. I'm using Keil as an IDE, although I don't mind using CCS. I can copy the program image, if it's equivalent to copying data from one memory address to the other, however, after some basic googling I noticed that I'll need to make my code position independent, and I don't know how to go about doing that. 

I wish to do so to read code off an external flash and execute it.

P.S. I m just a student, and above is a hobby project that I wish to do. Any help on the same is appreciated :)

  • 0
    Guru 117855 points

    Greetings,

    May my firm's young staff/I note your writing as excellent!    Note too - many/most "here" - at one time - were "students..."

    In our many years of MCU-based design/development - we cannot recall the application/activity you describe.   Might you describe your "intent" and/or the "value proposition" resulting from your, "Copy of Program Image from External Flash to SRAM - and then execution from SRAM?

    Would a "more direct method" see your (ideally small) program entered (normally) into MCU's Flash - and then copied to SRAM - and then executed?    The (likely), "Program Load into - followed by Read from External Flash" into MCU's SRAM - appears to introduce added demands - and any advantage so achieved - escapes our quick recognition...

    Our group uses multi-seat IAR (IDE) ... transfer from "MCU's Flash to SRAM - and then Execution" is well detailed w/in the IDE's "Help" section...   Perhaps that's a "speeded/eased Bridge" to your objective...

  • 0 in reply to cb1_mobile
    Prodigy 210 points

    Hi,

    Actually I saw that many devices perform FOTA-like upgrades in a similar manner. But couldn't really understand their implementation.

    We can remove external flash from the picture for now.

    It would be really helpful if you can give some insight on how to copy some code from internal flash to SRAM and then execute it from there (SRAM) .

    Also, the book by Dr. Joseph Yiu, states that we can execute code out of SRAM for Cortex M based MCUs and power off the flash in order to save power. Also SRAM accesses are faster.

    The idea I have is to write a bootloader, that copies "important" part of the code to the SRAM and transfer control to it.

    The following, is just theory for now :

    To me it seems I can write a function to copy the code, and then modify the PC value present in the Exception Stack through some interrupt - ISR (like SysTick).  That PC value would actually be the address of code present in SRAM.

    But I read articles and forums claiming that it's not that straight forward.

    Any insight on stuff I m missing is appreciated. :)

  • 0 in reply to Pranjal Shrivastava
    Guru 117855 points

    Kindly take a (new) look at the last paragraph w/in our earlier response.   Our tech group employs many ARM MCUs - from many vendors - I'm not so sure that we've implemented your objective (w/in recent memory) w/your MCU.

    We've long had Mr. Yiu's book - find him skilled & the book powerful.   That said - our scan found (No or hidden) mention of "code execution" from SRAM.    (I know we've done that - yet the method varies somewhat between different vendor's devices.)

    To your Bootloader goal - this vendor has produced highly detailed Boot-Loader Guides - it is highly recommended that you (seriously) review these - prior to implementing your "theory."

    In closing - any "speed-up" resulting from "SRAM over Flash" pales when compared to (numerous) ARM MCUs (long) operating at far higher System Clocks.   (one recent ARM device reaches to 600MHz - yet has been adopted (primarily - for now) by hobbyists!)

  • 0 in reply to cb1_mobile
    Prodigy 210 points

    Hi,

    I'll surely check with IAR. Hopefully that helps.

    Also when you mentioned "this vendor" for bootloader guides, do you mean IAR?

    As far as Mr. Yiu's book is concerned. I'd refer you to this newer version of it.

    Chapter 9 : Low Power and System Control. Page 310.

    Thanks and Regards

  • 0 in reply to Pranjal Shrivastava
    TI__Guru 72500 points

    We have an example that does much of what I think you want to do. Instead of position independent code, the code is generated with a load address that is different from its run address. The load address is what is used when the code is programmed into flash, the run address is the address it will be executed from, usually RAM. Look at the example in: C:\ti\TivaWare_C_Series-2.1.4.178\examples\boards\dk-tm4c123g\boot_serial

    The tricky parts are in the startup assembly file and the linker command file. Since both of these files are code generation tool specific, there are versions of each of these files for TI Code Composer studio (CCS), IAR, Keil and GCC. 

    The CCS startup file is bl_startup_ccs.s. The function ProcessorInit copies the whole bootloader to SRAM, initializes the .bss section, sets the hardware interrupt vector unit to look for vectors at the beginning of SRAM and then changes its return address to jump to RAM instead of flash.

        .thumbfunc ProcessorInit
ProcessorInit: .asmfunc
    ;;
    ;; Copy the code image from flash to SRAM.
    ;;
    movs    r0, #0x0000
    movs    r1, #0x0000
    movt    r1, #0x2000
    ldr     r2, bss_start
copy_loop:
        ldr     r3, [r0], #4
        str     r3, [r1], #4
        cmp     r1, r2
        blt     copy_loop

    ;;
    ;; Zero fill the .bss section.
    ;;
    movs    r0, #0x0000
    ldr     r2, bss_end
zero_loop:
        str     r0, [r1], #4
        cmp     r1, r2
        blt     zero_loop

    ;;
    ;; Set the vector table pointer to the beginning of SRAM.
    ;;
    movw    r0, #(NVIC_VTABLE & 0xffff)
    movt    r0, #(NVIC_VTABLE >> 16)
    movs    r1, #0x0000
    movt    r1, #0x2000
    str     r1, [r0]

    ;;
    ;; Set the return address to the code just copied into SRAM.
    ;;
    orr     lr, lr, #0x20000000

    ;;
    ;; Return to the caller.
    ;;
    bx      lr
    .endasmfunc

    The CCS linker command file gives all of the code that goes into flash a RAM based address and defines some global symbols that reference the Load address, the Run address and the size of the code.

    MEMORY
{
    FLASH (RX) : origin = 0x00000000, length = 0x00010000
    SRAM (RWX) : origin = 0x20000000, length = 0x00010000
}

/* Section allocation in memory */

SECTIONS
{
    GROUP
    {
        .intvecs
        .text
        .const
        .data
    } load = FLASH, run = 0x20000000, LOAD_START(init_load), RUN_START(init_run), SIZE(init_size)

    GROUP
    {
        .bss
        .stack
    } run = SRAM, RUN_START(bss_run), RUN_END(bss_end), SIZE(bss_size), RUN_END(__STACK_TOP)

}

  • 0 in reply to Pranjal Shrivastava
    Guru 117855 points

    Thank you - that SRAM detail (may) not have made it into our "10 year old edition."   (being 'early' proves not always an advantage - except when talking Product Introductions!)

    Bootloader Guides - rich in detail - are by TI - and provide great flexibility & accommodation.    (the IDE may 'touch' on boot-loaders - but never nearly in such (necessary) detail).

    Our book lists Chapt. 9 as "Interrupt Behavior" - starts at page 145.   There is no chapter as you've noted.   (yet we did just find an "sram" mention - which was nowhere included w/in the book's index.)

    Seriously - your "find & read" of TI's bootloader guides (there are several) will prove of great value...

  • 0 in reply to Bob Crosby
    Prodigy 210 points

    Hi Bob, 

    Thanks for the reply! Can you please link that version of TivaWare here? It would be a big help! :)

    The one I have doesn't include the examples folder.

    Regards

    Pranjal

  • 0 in reply to Pranjal Shrivastava
    TI__Guru 72500 points

    http://www.ti.com/tool/SW-TM4C

    Select the first "Get Software" button to download the complete library with the examples and document.

  • 0 in reply to cb1_mobile
    Prodigy 210 points

    Hi cb1_mobile, 

    Thanks for that reference, it will be great if you can put on some link of that Bootloader Guide here, thanks! 

    And yes, that chapter isn't present in the older version of this book, I just checked that.

    Thank you so much for your help ! :) 

  • 0 in reply to Pranjal Shrivastava
    Guru 117855 points

    Voici mon ami,

    TivaWARE\docs\SW-TM4C-BOOTLDR-UG-2.1.4.178

    It may be wise to mention that boot-loaders demand:

    • great attention to (even) fine detail
    • some indirection
    • solid testing to confirm that your implementation has succeeded

    My tech group believes that if the primary purpose of such "boot-loader" is to, "Avoid the acquisition & use of a JTAG Probe" - then that purpose proves "mistaken."   Boot-Loaders are sufficiently complex as to demand "much" of your pending time & attention.    Your development & mastery of the "Key MCU Elements & Code Exploration" may be delayed (sometimes chronically) in the pursuit of the boot-loader.

    In addition - a proper JTAG probe will always (and significantly) "Speed, Ease & Enhance" your MCU Programming & Debugging.   JTAG probes are considered a "vital" development tool...   

    Rarely should the boot-loader be an "early task" - necessary experience gained via "Study of the MCU Manual & intensive program example (API) review" best prepares one for the pending challenge...   (MCU Search-Box (up top) will reveal many hundreds of posts from "too early" boot-loader implementations...)