Overview

The SRAM integration path answers a different question than the raw validation suite:

"Can the firmware safely use external SRAM for initialized application data?"

This is implemented in sram_integration.c and depends on startup support from globalDataCopy.s plus linker support from STM32H753ZITX_FLASH.ld.

Linker and Startup Flow

The integration flow depends on three coordinated elements:

a custom .sramdata linker section placed into external SRAM at runtime
a FLASH load image for that section
a startup copy routine that copies initialized contents from FLASH into external SRAM before the integration tests run

The startup copy routine uses linker-defined symbols:

_sisram : FLASH load address of .sramdata
_ssramdata : SRAM start address of .sramdata
_esramdata : SRAM end address of .sramdata

Initial Structure Verification

The integration test declares initialized objects in .sramdata, prints them after startup copy, modifies selected fields, and then performs a self-checking PASS/FAIL verification.

Retained Diagnostic Coverage

The H753 project intentionally keeps the staged raw byte-dump diagnostics in SramIntegration_RunStructRawDumpTest(). Those diagnostics proved useful during the H753 investigation because they made it possible to see exactly which bytes changed after each update phase.

Build-Time Flow Selection

The build-time switch SRAM_INTEGRATION_TEST_ENABLE in main.c is used to select this integration-oriented execution path explicitly.

When the macro is enabled:

firmware initialization still configures the platform normally
globalDataCopy() runs so initialized .sramdata content is copied from FLASH into external SRAM
SramIntegration_RunStructTest() executes
SramIntegration_RunStructRawDumpTest() executes as an additional diagnostic/regression aid

When the macro is disabled:

the firmware follows the default validation-oriented flow
SramValidation_RunAll() runs and may overwrite broad SRAM regions