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

3.1 Overview

The runtime code overlay methodology presented in this application note separates the software into two categories: a resident runtime and transient overlay payloads.

The resident runtime remains loaded throughout system execution and is responsible for payload management, FATFS access, code relocation, cache maintenance, and execution control. Overlay payloads are stored as executable package files in eMMC FATFS and are loaded only when execution is requested.

Instead of reserving dedicated memory for each software module, all payloads share a common SRAM execution region. The same SRAM region can be reused repeatedly by different payloads during runtime.

Runtime Code Overlay Methodology and Control FlowFigure 3-1 Runtime Code Overlay Methodology and Control Flow.