{"id":75,"date":"2025-08-31T05:11:40","date_gmt":"2025-08-31T05:11:40","guid":{"rendered":"https:\/\/xtronix.in\/?p=75"},"modified":"2025-08-31T05:11:40","modified_gmt":"2025-08-31T05:11:40","slug":"start-up-and-linker-comparison","status":"publish","type":"post","link":"https:\/\/xtronix.in\/?p=75","title":{"rendered":"Start-up and linker Comparison"},"content":{"rendered":"\n

Comparing the startup and linker files across these architectures reveals a lot about their core design philosophies, from the simple, linear memory models of older architectures to the complex, vendor-specific ecosystems of modern ones.<\/p>\n\n\n\n

Here is a detailed comparison, breaking down the purpose, key components, and architectural implications for each family.<\/p>\n\n\n\n

Executive Summary<\/h3>\n\n\n\n
Microcontroller<\/th>Startup File Purpose<\/th>Linker File Purpose<\/th>Key Characteristics & Philosophy<\/th><\/tr><\/thead>
8051<\/strong><\/td>Minimal. Copies initialized data from CODE to DATA memory.<\/td>Simple. Manages segments in overlapping physical memory.<\/td>Classic Harvard.<\/strong> Complex memory banking. Manual segment placement is common.<\/td><\/tr>
PIC (8-bit)<\/strong><\/td>Minimal. Clears RAM, copies initialized data. Often in assembly.<\/td>Defines memory regions and sections. Manages paging\/banking.<\/td>Harvard Architecture.<\/strong> Banked memory. Simple and explicit, but can be cumbersome.<\/td><\/tr>
AVR (8-bit)<\/strong><\/td>Initializes stack, copies .data, clears .bss, jumps to main().<\/td>Defines FLASH, RAM, EEPROM regions and places sections.<\/td>Clean, Modern Harvard.<\/strong> Linear memory spaces. Very straightforward and predictable.<\/td><\/tr>
MSP430<\/strong><\/td>Initializes stack, copies .data, clears .bss, calls constructors, jumps to main().<\/td>Defines FLASH and RAM regions. Manages low-power info and interrupt vectors.<\/td>Von Neumann.<\/strong> Unified memory space. Simple and efficient 16-bit RISC design.<\/td><\/tr>
ARM (Cortex-M)<\/strong><\/td>Highly Complex.<\/strong> Sets up stacks, vectors, clocks, RAM, calls C++ constructors.<\/td>Highly Complex.<\/strong> Manages multiple memory regions, defines entry point, heap\/stack.<\/td>Core Agnostic.<\/strong> The core provides standard (CMSIS), vendors provide complex implementations for their specific chips.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n

Detailed Breakdown<\/h3>\n\n\n\n

1. 8051<\/h4>\n\n\n\n

Architecture:<\/strong> Harvard, with separate address spaces for code and data. Memory is highly banked.<\/p>\n\n\n\n

    \n
  • Startup File:<\/strong>\n
      \n
    • Purpose:<\/strong> Primarily to copy initialized variables from program memory (CODE\/ROM) into the default data memory bank (DATA\/RAM). On power-up, RAM is uninitialized.<\/li>\n\n\n\n
    • Key Actions:<\/strong>\n
        \n
      1. Initialize Stack:<\/strong> The stack is usually located in the IDATA (internal RAM) region.<\/li>\n\n\n\n
      2. Data Initialization:<\/strong> A loop that copies the initial values of variables from the ?C_INITSEG<\/code> (or similar) code segment to the ?DT?*<\/code> data segments.<\/li>\n\n\n\n
      3. Jump to main():<\/strong> Transfers control to the C program’s entry point.<\/li>\n<\/ol>\n<\/li>\n\n\n\n
      4. Complexity:<\/strong> Low to Medium. The logic is simple, but understanding the banked memory model is crucial.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
      5. Linker File (.l51, .lx51):<\/strong>\n
          \n
        • Purpose:<\/strong> To manage the complex, overlapping memory spaces (CODE, XDATA, PDATA, DATA, IDATA, BIT) and assign segments to the correct physical addresses and banks.<\/li>\n\n\n\n
        • Key Components:<\/strong>\n
            \n
          • MEMORY<\/code>: Defines the physical memory ranges (e.g., CODE(0x0000, 0x7FFF)<\/code>, XDATA(0x0000, 0xFFFF)<\/code>).<\/li>\n\n\n\n
          • SECTIONS<\/code>: Tells the linker which programmer-defined segments (like ?PR?main?MAIN<\/code> for the code of main()<\/code> in file MAIN.C<\/code>) to place in which memory region.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
          • Philosophy:<\/strong> Explicit and Manual.<\/strong> The developer often needs to be deeply aware of memory banking and manually place critical functions (using n<\/code>) or variables in specific banks for efficiency.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

            2. PIC (8-bit)<\/h4>\n\n\n\n

            Architecture:<\/strong> Harvard. Heavily banked memory (both RAM and ROM).<\/p>\n\n\n\n

              \n
            • Startup File (crt0.s \/ startup.as):<\/strong>\n
                \n
              • Purpose:<\/strong> Performs very basic initialization before main()<\/code>.<\/li>\n\n\n\n
              • Key Actions:<\/strong>\n
                  \n
                1. Initialize Stack:<\/strong> Sets up the hardware stack (which is often separate and limited in depth).<\/li>\n\n\n\n
                2. Clear RAM:<\/strong> Zeros out the general-purpose RAM.<\/li>\n\n\n\n
                3. Copy Data:<\/strong> Copies initialized variables from program memory to data memory.<\/li>\n\n\n\n
                4. Jump to main()<\/strong>.<\/li>\n<\/ol>\n<\/li>\n\n\n\n
                5. Complexity:<\/strong> Low. Often written in assembly and provided by the compiler toolchain (MPLAB XC8).<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                6. Linker File (.lkr):<\/strong>\n
                    \n
                  • Purpose:<\/strong> To describe the memory layout of the specific<\/em> target PIC microcontroller and assign code and data sections to the appropriate program and data memory banks.<\/li>\n\n\n\n
                  • Key Components:<\/strong>\n
                      \n
                    • CODEPAGE<\/code>: Defines blocks of program memory (ROM).<\/li>\n\n\n\n
                    • DATABANK<\/code>: Defines blocks of data memory (RAM banks).<\/li>\n\n\n\n
                    • SECTION<\/code>: Directs standard sections (e.g., .text<\/code>, .data<\/code>) to the defined memory areas.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                    • Philosophy:<\/strong> Bank-Centric.<\/strong> The linker script is crucial for managing bank switching. If a section spans multiple banks, the linker must generate the appropriate “bank selection” instructions.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

                      3. AVR (e.g., ATmega328P)<\/h4>\n\n\n\n

                      Architecture:<\/strong> Modified Harvard. Has separate, linear address spaces for Flash (program) and RAM (data).<\/p>\n\n\n\n

                        \n
                      • Startup File (crt0.o \/ gcrt0.o):<\/strong>\n
                          \n
                        • Purpose:<\/strong> A classic, clean example of a startup routine for an embedded system.<\/li>\n\n\n\n
                        • Key Actions:<\/strong>\n
                            \n
                          1. Initialize Stack Pointer:<\/strong> Sets the SP to the end of RAM.<\/li>\n\n\n\n
                          2. Copy .data:<\/strong> Copies the initial values from Flash (.data section) to SRAM.<\/li>\n\n\n\n
                          3. Clear .bss:<\/strong> Zeros out the uninitialized data section in SRAM.<\/li>\n\n\n\n
                          4. Call main():<\/strong> Jumps to the user’s main()<\/code> function.<\/li>\n<\/ol>\n<\/li>\n\n\n\n
                          5. Complexity:<\/strong> Low. Very straightforward and easy to understand.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                          6. Linker File (.ld):<\/strong>\n
                              \n
                            • Purpose:<\/strong> To define the memory layout (Flash, RAM, and EEPROM) and section placement for the target AVR chip.<\/li>\n\n\n\n
                            • Key Components:<\/strong>\n
                                \n
                              • MEMORY<\/code>: Declares the size and origin of Flash (rx), RAM (rwx), and EEPROM (r).<\/li>\n\n\n\n
                              • SECTIONS<\/code>: Defines where to place .text<\/code>, .data<\/code>, .bss<\/code>, .noinit<\/code>, and .eeprom<\/code> sections.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                              • Philosophy:<\/strong> Transparent and Linear.<\/strong> The memory map is simple and linear, making linker scripts easy to write and modify. The avr-libc provides excellent default scripts.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

                                4. MSP430<\/h4>\n\n\n\n

                                Architecture:<\/strong> Von Neumann. Has a unified address space for RAM and Flash.<\/p>\n\n\n\n

                                  \n
                                • Startup File (startup_<device>.c \/ .s):<\/strong>\n
                                    \n
                                  • Purpose:<\/strong> Similar to AVR but often includes more functionality, especially for low-power modes and C++.<\/li>\n\n\n\n
                                  • Key Actions:<\/strong>\n
                                      \n
                                    1. Disable Watchdog:<\/strong> A critical first step on MSP430.<\/li>\n\n\n\n
                                    2. Set up Stack Pointer.<\/strong><\/li>\n\n\n\n
                                    3. Copy .data:<\/strong> From Flash to RAM.<\/li>\n\n\n\n
                                    4. Clear .bss.<\/strong><\/li>\n\n\n\n
                                    5. Call C++ Constructors:<\/strong> For global objects (if using C++).<\/li>\n\n\n\n
                                    6. Call main()<\/strong>.<\/li>\n<\/ol>\n<\/li>\n\n\n\n
                                    7. Complexity:<\/strong> Low to Medium. TI’s Code Composer Studio provides well-commented startup files for each device family.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                    8. Linker File (.cmd):<\/strong>\n
                                        \n
                                      • Purpose:<\/strong> To define the unified memory map and assign sections to either Flash or RAM.<\/li>\n\n\n\n
                                      • Key Components:<\/strong>\n
                                          \n
                                        • MEMORY<\/code>: Defines ranges (e.g., FLASH : origin = 0x8000, length = 0x7FFF<\/code>, RAM : origin = 0x2000, length = 0x1000<\/code>).<\/li>\n\n\n\n
                                        • SECTIONS<\/code>: Assigns .text<\/code>, .data<\/code>, .bss<\/code>, .stack<\/code>, and, crucially, the INTERRUPT VECTOR TABLE<\/strong> to specific addresses.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                        • Philosophy:<\/strong> Unified and Efficient.<\/strong> The unified memory space simplifies the linker script compared to banked Harvard architectures. The focus is on efficient placement of code and data between volatile (RAM) and non-volatile (Flash) memory.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

                                          5. ARM (Cortex-M)<\/h4>\n\n\n\n

                                          Architecture:<\/strong> Von Neumann or Harvard (depending on specific core), but presented with a unified memory map.<\/p>\n\n\n\n

                                            \n
                                          • Startup File (startup_<device>.s):<\/strong>\n
                                              \n
                                            • Purpose:<\/strong> Extremely complex and critical.<\/strong> It does far more than just initialize variables.<\/li>\n\n\n\n
                                            • Key Actions:<\/strong>\n
                                                \n
                                              1. Initialize the Stack Pointer<\/strong> from the first entry in the vector table.<\/li>\n\n\n\n
                                              2. Initialize the Process Stack Pointer<\/strong> (on cores that support it).<\/li>\n\n\n\n
                                              3. Set the Vector Table Offset Register (VTOR)<\/strong>.<\/li>\n\n\n\n
                                              4. Copy .data from Flash to RAM.<\/strong><\/li>\n\n\n\n
                                              5. Zero out the .bss section.<\/strong><\/li>\n\n\n\n
                                              6. Configure System Clock and PLL.<\/strong> (Often done in SystemInit()<\/code> called before main<\/code>).<\/li>\n\n\n\n
                                              7. Call C++ Constructors<\/strong> (for global objects, __libc_init_array<\/code>).<\/li>\n\n\n\n
                                              8. Call main()<\/strong>.<\/li>\n<\/ol>\n<\/li>\n\n\n\n
                                              9. Complexity:<\/strong> High.<\/strong> This file is highly vendor-specific (ST, NXP, TI, etc.) and is often provided as part of a Device Family Pack (DFP) or Hardware Abstraction Layer (HAL). It’s tightly coupled with the system initialization code.<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                              10. Linker File (.ld \/ .icf \/ .sct):<\/strong>\n
                                                  \n
                                                • Purpose:<\/strong> To define the complex memory map of a modern ARM SoC, which often includes multiple Flash banks (for dual-banking\/OTA updates), multiple RAM banks (core, DMA, TCM), and peripheral memory.<\/li>\n\n\n\n
                                                • Key Components:<\/strong>\n
                                                    \n
                                                  • MEMORY<\/code>: Extensive definition of all memory regions (e.g., FLASH<\/code>, RAM<\/code>, CCMRAM<\/code>, BACKUP_SRAM<\/code>).<\/li>\n\n\n\n
                                                  • SECTIONS<\/code>: Detailed placement of:\n
                                                      \n
                                                    • .isr_vector<\/code>: The interrupt vector table (must be placed at correct base address).<\/li>\n\n\n\n
                                                    • .text<\/code>: Code and constants.<\/li>\n\n\n\n
                                                    • .data \/ .bss<\/code>: Initialized\/Uninitialized data.<\/li>\n\n\n\n
                                                    • ._user_heap_stack<\/code>: Defines the heap and stack areas.<\/li>\n\n\n\n
                                                    • Special sections for other cores (e.g., .ARM.exidx<\/code> for exception unwinding).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n\n\n\n
                                                    • Philosophy:<\/strong> Flexible and Powerful.<\/strong> ARM linker scripts are the most complex, offering fine-grained control over memory layout. They are essential for optimizing performance (placing critical code in fast TCM RAM) and enabling advanced features like bootloaders.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

                                                      Conclusion<\/h3>\n\n\n\n

                                                      The evolution from 8051\/PIC<\/strong> to AVR\/MSP430<\/strong> to ARM<\/strong> shows a clear trend:<\/p>\n\n\n\n

                                                        \n
                                                      1. From Manual to Automatic:<\/strong> Moving away from manual memory banking to automated, linear(ish) memory models.<\/li>\n\n\n\n
                                                      2. From Simple to Complex:<\/strong> As microcontrollers became more powerful, the startup and linker processes grew to handle complex silicon features like multiple memory types, system clocks, and C++ support.<\/li>\n\n\n\n
                                                      3. From Vendor-Agnostic to Vendor-Specific:<\/strong> While the ARM core<\/em> is standard, the implementation (startup and linker files) is entirely vendor-specific, abstracted away by powerful IDEs and configuration tools (STM32CubeMX, MCUXpresso). For 8051\/PIC\/AVR, the files are simpler but often require more manual intervention from the developer.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

                                                        Comparing the startup and linker files across these architectures reveals a lot about their core design philosophies, from the simple, linear memory models of older architectures to the complex, vendor-specific ecosystems of modern ones. Here is a detailed comparison, breaking down the purpose, key components, and architectural implications for each family. Executive Summary Microcontroller Startup […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/xtronix.in\/index.php?rest_route=\/wp\/v2\/posts\/75"}],"collection":[{"href":"https:\/\/xtronix.in\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/xtronix.in\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/xtronix.in\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/xtronix.in\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=75"}],"version-history":[{"count":1,"href":"https:\/\/xtronix.in\/index.php?rest_route=\/wp\/v2\/posts\/75\/revisions"}],"predecessor-version":[{"id":76,"href":"https:\/\/xtronix.in\/index.php?rest_route=\/wp\/v2\/posts\/75\/revisions\/76"}],"wp:attachment":[{"href":"https:\/\/xtronix.in\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=75"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/xtronix.in\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=75"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/xtronix.in\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=75"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}