SDAA362 June   2026 TDA4VE-Q1

 

  1.   1
  2.   Abstract
  3.   Trademarks
  4. 1Introduction
  5. 2Runtime Code Overlay Background
    1. 2.1 Memory Architecture of TDA4x
    2. 2.2 Challenges of Static Code Allocation
    3. 2.3 Why Runtime Code Overlay?
  6. 3Runtime Code Overlay Methodology
    1. 3.1 Overview
    2. 3.2 Resident Runtime
    3. 3.3 Overlay Payload package
    4. 3.4 Shared SRAM Overlay Region
    5. 3.5 Runtime Overlay Sequence
  7. 4Runtime Code Overlay Architecture
    1. 4.1 Software Architecture
    2. 4.2 Overlay Package Format
    3. 4.3 Memory Layout
    4. 4.4 Runtime Image Loading
    5. 4.5 Runtime Execution
  8. 5Demo Implementation
    1. 5.1 Software Organization
    2. 5.2 Overlay SRAM Configuration
    3. 5.3 Payload Generation
    4. 5.4 Payload Loading and Execution
    5. 5.5 Build Configuration
  9. 6Runtime Code Overlay Verification
    1. 6.1 PayloadA Execution
    2. 6.2 PayloadB Execution
    3. 6.3 PayloadC Execution
    4. 6.4 Shared SRAM Overlay Slot Reuse
    5. 6.5 Complete Runtime Verification
  10. 7Summary
  11. 8References

Challenges of Static Code Allocation

A common software deployment model statically links all executable modules into a single application image. During system initialization, the entire executable image is loaded into memory and remains resident throughout runtime.

While this approach simplifies software management, it permanently allocates memory for every software feature regardless of actual usage. As the number of software modules increases, the memory footprint of the resident runtime environment also increases.

Examples of software components that may not be required continuously include

• Diagnostic functions

• Recovery utilities

• Factory test functions

• Service tools

• Feature-specific application modules

Keeping all such components resident simultaneously may lead to inefficient memory utilization.