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.

Compiler/TM4C1294NCPDT: Why are boot loaders set to initialize global variables at load time?

Part Number: TM4C1294NCPDT

Tool/software: TI C/C++ Compiler

In the USB Serial Device Firmware Upgrade tutorial/guide, you are told to set the boot loader linker settings to initialize global variables at load time (--ram_model, -cr).

However, reading the Arm Compiler User Guide 6.10.3.3 says this about the alternative run time initialization (--rom_model) "Use this method in any system where your application runs from code burned into ROM".

The project settings in the DFU tutorial seem to contradict this statement. The project being upgraded gets the setting meant for applications "burned into ROM". The permanent boot loader does not get this setting.

Why does the DFU tutorial have these settings? Why do these setting seem to contradict the compiler guide's statement?

  • While I am as helpful (here) as a "Pet Rock" - your posting proves, "Outstanding!"         (even to this rock dweller)

    Superbly detailed - justified via (findable/identifiable) sources - and "crystal clear" in its objectives...

  • Hi Peter,
    Typically the flash bootloader exists in the flash but is then copied into RAM for execution. (Otherwise it cannot erase or reprogram the flash bank that it resides in.) Therefore the bootloader "runs" from RAM, and the --ram_model for variable initialization is appropriate.
  • Hello Peter,

    By the USB Serial Device Firmware Upgrade Tutorial, are you referring to the TivaWare examples for USB Boot Loader like boot_serial?

    In the case of the Flash boot loader, my understanding is the ram_model feature is used because of how the Flash boot loader should have all the variables initialized at load time as "Initialization of variables at load time enhances performance by reducing boot time and by saving the memory used by the initialization tables" This is my understanding after reading Section 6.10.3.5 of the ARM Compiler guide which details the ram_model feature.

    Note that the Flash boot loader is not equivalent to the ROM boot loader which executes when there is no data present in TM4C Flash. Therefore it is not solely running from code burned into ROM (though it does leverage ROM API's).

    Regarding why projects being loaded in via the boot loader use the rom_model setting, these projects would not need the rapid initialization and should have the variables loaded in at run time in which the rom_model option is best served to be used as is done across all our non-boot loader examples.

    By the way for any future readers, the ARM Compiler User's Guide being referenced is the TI specific guide found here: www.ti.com/.../spnu151m.pdf

    Also another useful resource may be the ARM Assembly Language Tools User Guide: www.ti.com/.../spnu118u.pdf where Section 3.3.2 has some more info on RAM vs ROM Model.

    Hopefully this helps address your question, please let me know if you have any doubts or follow-up questions.
  • ...well I guess my answer is just background overly detailed fluff compared to Bob's very precise reply. :)
  • Pardon - but agreed.     "Space IS available" w/in "rock dwelling."    (although going ... FAST)

  • I was working with the bootloader downloaded from a tutorial on the wiki: processors.wiki.ti.com/.../TI-RTOS_USB_DFU

    It works with the RTOS example project "USB Serial Device".

    The end goal is to have an ethernet based firmware update program. The intermediate goal is to understand what is being set in this guide.

    TivaWare installed with an example called boot_emac_flash. I hope its configuration follows the same instructions.

  • Why does the bootloader run from SRAM?
  • You cannot program any sector in a flash bank that you are executing from. Running from RAM allows the bootloader to reprogram any sector of flash.