S7-1200 Floating Boundary Memory: Program vs Data Layout

Overview of the S7-1200 Memory Architecture

The SIMATIC S7-1200 family uses a unified work memory pool in which both program code (OBs, FCs, FBs) and data block contents (DBs, M memory) coexist. The boundary between these two regions is described by Siemens as a floating boundary, meaning there is no fixed partition wall enforced by firmware. The CPU firmware dynamically allocates each block into the 50 KB (or 75/100/125/150 KB depending on CPU) work memory pool at download time and at every online block reallocation. This behavior is documented in the S7-1200 Programmable Controller System Manual (entry ID 36932465).

For an S7-1200 application, three memory areas matter during engineering:

• Load memory — non-volatile storage of project blocks on the internal flash or external SIMATIC Memory Card.
• work memory — volatile runtime area in which the CPU executes code and operates on DB contents.
• Retentive memory — a configurable subset of work memory that survives power-down and warm restart.

The floating boundary applies only to the work memory pool. Load memory and retentive memory are governed by separate rules and are not part of the floating boundary concept.

What “Floating Boundary” Means in Firmware

In classic S7-300/400 firmware, the work memory was split into two fixed regions at project compile time:

• A code area reserved exclusively for OB, FB, FC and SFC/SFB code.
• A data area reserved for instance DBs, global DBs, and system data.

If a project ran out of code space, adding more DBs would not help — the unused data area was stranded. Conversely, a project with many DBs and little code could not use the surplus data area for additional logic.

S7-1200 firmware removes that static split. Inside the 50 KB work memory pool, the firmware places:

The boundary between code and data is “floating” because the firmware can allocate the last free byte of work memory to whichever block class still needs space. The TIA Portal download dialog reports usage as a single percentage, not as two separate bars.

Work Memory vs Load Memory vs Retentive Memory

Three distinct memory concepts are commonly confused. The following definitions come from the S7-1200 system manual and the TIA Portal help on PLC concepts > data types.

Work Memory Sizes by CPU Model

The S7-1200 line spans CPUs 1211C, 1212C, 1214C, 1215C, 1217C and the second-generation 1212C/1214C/1215C/1217C variants. Work memory differs by model:

Firmware 4.x CPUs released in 2018 roughly doubled work memory for the 1214C and 1215C. To check your CPU version, read the Module Information > Identification tab in TIA Portal Online & Diagnostics; the Version field shows the firmware build (e.g. V4.2.1).

How the Floating Boundary Behaves at Compile Time

When TIA Portal compiles a project, it walks every block in the program tree and computes the byte count of:

1. Each OB header and body, including local stack requirements.
2. Each FB and FC code plus the FC/FB interface descriptor.
3. Each DB body. For FBs with multiple instance DBs, every instance is summed.

The compiler outputs a single Resource consumption summary in the project properties. If the sum exceeds the work memory of the target CPU, the download is rejected with diagnostic buffer entry 0x03E8 (resource exhaustion). The boundary is determined at compile time, not at runtime, even though the firmware can re-paginate blocks during online operations.

The TIA Portal Online & Diagnostics > Memory view shows three values for the active CPU:

• Work memory used: percentage of RAM currently holding live blocks.
• Load memory used: percentage of internal flash occupied by the project.
• Retentive memory used: bytes of the retentive range currently declared.

There is no separate display of “code area” or “data area” usage — confirming the floating boundary in practice.

Configuring Memory: What You Can and Cannot Change

The floating boundary cannot be moved manually. There is no TIA Portal parameter, no SFC call, and no SDO index that lets you reserve 40 KB for code and 10 KB for data. The CPU firmware owns that decision.

What you can configure under PLC properties > General > Memory and retentive memory:

Optimizing Code and Data Size Inside the Boundary

Because the boundary cannot be steered, the only practical levers are block-by-block size reduction. The following techniques are taken from the S7-1200 system manual and Siemens application examples.

Compact Code Patterns

• Replace multi-instance DBs with single-instance DBs when the calling FB depth is shallow — each multi-instance block adds a header overhead of roughly 60–120 bytes.
• Use SCL ARRAY structures inside one DB instead of dozens of scalar tags, reducing the DB header per element.
• Move rarely used FBs to a library that is only loaded when needed, or split the program into two CPUs networked over PROFINET.
• Delete unused FC/FB stubs. The compiler keeps all referenced blocks; an unreferenced FB still consumes no work memory but the symbol table entry does not. Confirm with Project tree > Common data > Cross-references.

Compact Data Patterns

• Prefer BOOL bit-packed tags inside a single DB rather than isolated M flags when the total tag count exceeds 32.
• Use WORD/DWORD/LREAL over INT/REAL only when the precision is justified; every tag carries a 2-byte descriptor on top of its raw width.
• Drop symbolic comments from DBs that are written to the SIMATIC Memory Card — the comment is stored in load memory, but descriptor growth still increases compile time and SDB size.

Disabling Block Interface Helpers

For each FB, the Properties > General > Interface parameters page contains options that consume work memory:

Diagnosing Memory Pressure in TIA Portal

Use the following procedure to inspect memory consumption on a live CPU.

1. Connect TIA Portal to the CPU and open Online & Diagnostics.
2. Select the Memory tile. The panel reports bytes used / bytes total for work, load, and retentive areas.
3. Click Save as text to log current consumption. Compare to the same report from the offline project to see the block that grew unexpectedly.
4. Open the Diagnostic buffer and search for entries with error code 0x03E8 or 0x03E9; these indicate work memory exhaustion events.
5. Run Project tree > PLC > Compile > Software (rebuild all blocks) and review the new resource report.

CPU diagnostic buffer entries that frequently accompany memory issues:

Comparison With Older SIMATIC Families

Engineers migrating from S7-200, S7-300, or S7-400 are accustomed to fixed code/data splits. The table below summarizes the change.

The S7-1500 family inherited the floating boundary from S7-1200 and applies the same model, but with a much larger work memory base (300 KB on CPU 1511 up to 6 MB on CPU 1518).

Edge Cases and Field-Proven Caveats

The following behaviors are reported in Siemens support notes and confirmed in system manual revision history.

1. Library blocks inserted from the Siemens library are counted at compile time even if you never reference them in the active program. Remove the Library reference from the Libraries pane rather than just leaving the FB in the tree.
2. Know-how protected blocks add roughly 256 bytes of SDB overhead each. On a CPU 1211C, protecting more than 30 FBs may push the project past 30 KB.
3. Web server DB (generated automatically by TIA Portal when web server is enabled) consumes ~12 KB. Disable the web server for low-memory CPUs.
4. Recipe DBs and data logs live in load memory on the SIMATIC Memory Card; they do not count against work memory, but their schemas must fit in DBs that do.
5. Function block with very large TEMP interface (e.g. 4 KB of local stack) consumes work memory at every instance. Move large temporaries to a global DB and use POKE_BLK for buffer passing.

Verification Procedure After a Download

After a memory-sensitive download, run the following checklist:

1. In Online & Diagnostics > Memory, confirm work memory used < 85% of total. The CPU is stable below this threshold; above 90%, STOP→RUN cycles can fragment work memory and trigger 0x03E8 on the next download.
2. Cycle a power-off/on test. Verify that all retentive M bytes and DB tags retain their last value. If the diagnostic buffer shows 0x0EF2, the retentive range is larger than the NVRAM slice and must be reduced.
3. Force a STOP→RUN transition ten times consecutively. Monitor the diagnostic buffer for memory warnings. A clean log after 10 cycles indicates headroom is adequate.
4. Trigger a Download to device > Software (all blocks) while the plant is in safe state. A successful second download confirms the project is reproducible and the CPU flash is healthy.

FAQ