init_table, zero_table and other ..._tables

HiddenSquid — Wed, 25 Mar 2026 09:13:27 GMT

Hello

I have a few questions about the purpose and usecase of the init_table and some other ..._tables defined in the startup.s of most demo projects.

Firstly, I'll try to explain how I have understood things work so far and I would like someone more knowledgeable to confirm or correct me, if I'm wrong.

I am dealing with S32E288 and trying to boot the R52_0_1 core as a secondary core. Now there are multiple tables:

init_table: Used for loading the entire code from flash/ROM to RAM.
zero_table: Used for loading uninitialised global or zero initialised variables to RAM.
stack_table: Used for initialising stack on per core basis with offset logic
xtcm_tables: Used for initalising Tightly Coupled Memory on a per core basis with offset logic
tcm_data_table: Used for loading Tightly Coupled Memory with data from RAM or ROM?
core_interrupts_init_table: Used for loading the Interrupt Vectors to RAM?
wdg_table: Used for disabling the watchdog on per core basis with offset logic

Now this is where the confusion kicks in a bit. I have understood from different sources that the init_table should be used by some other core or bootloader externally to load the entire code base (every larger section) from flash to RAM to the correct place and the each the core itself can run and use initialise itself by using the stack_, tcm_data_, wdg_, core_interrupts_init_ and xtcm_tables.

So it would look something like this:

Bootloader or the M33 SMU core
- Use the init_table of the R52_0_1 to load larger sections of RAM from FLASH

/* Table for copying and zeroing */ /* Copy table: - Table entries count - entry one ram start - entry one rom start - entry one rom end ... - entry n ram start - entry n rom start - entry n rom end Zero Table: - Table entries count - entry one ram start - entry one ram end */ .section ".init_table", "a" .long 4 .long __RAM_CACHEABLE_START .long __ROM_CACHEABLE_START .long __ROM_CACHEABLE_END .long __RAM_NO_CACHEABLE_START .long __ROM_NO_CACHEABLE_START .long __ROM_NO_CACHEABLE_END .long __RAM_SHAREABLE_START .long __ROM_SHAREABLE_START .long __ROM_SHAREABLE_END .long __RAM_INTERRUPT_START .long __ROM_INTERRUPT_START .long __ROM_INTERRUPT_END .section ".zero_table", "a" .long 3 .long __BSS_SRAM_SH_START .long __BSS_SRAM_SH_END .long __BSS_SRAM_NC_START .long __BSS_SRAM_NC_END .long __BSS_SRAM_START .long __BSS_SRAM_END

The R52_0_1 core
- The core now has code in a CRAM region where it can start executing code.
- The core should start executing (ENTRY_ADDRESS set as) at ETABLE:

.globl ETABLE ETABLE: b Reset_Handler b UndefInstr_Handler /* Branch to UndefInstr_Handler */ b SVC_Handler /* Branch to HVC_Handler/SVC_Handler */ b PrefetchAbort_Handler /* Branch to PrefetchAbort_Handler */ b DataAbort_Handler /* Branch to DataAbort_Handler */ b HVC_Handler /* Branch to HVC_Handler */ b IRQ_Handler /* Branch to IRQ_Handler */ b FIQ_Handler /* Branch to FIQ_Handler */

The first instruction at ETABLE points to Reset_Handler
Reset_Handler uses the other tables (tcm, stack, wdg etc...) to initialise the core and load specific regions from RAM to TCM (since bootloader does not have access to RAM?)
The core can then start executing code from it's own TCM for fastest and deterministic execution.

Now this bootflow does have some flaws... which is why I would like someone to confirm or correct me!

Firstly, what it the purpose of the zero_table and where does it fit in this boot logic? Should it be used by someone externally or by the core itself? Do I even need the zero_table, when I have initialised the entire RAM region using SRAM_CTL registers?
How does the external core know what is placed where within the core binary? I can use offset calculation with the raw binary format, but the .elf file format should also contain a sort of init_table? How should I interpret the .elf file format?
What is the difference between xtcm_init and tcm_data_tables?

/* Core CTCM table Ctcm_start_0 Ctcm_end_0 ... */ .section ".ctcm_table", "a" /* RTU0 R52_0 */ .long __INT_CTCM_START_0 .long __INT_CTCM_END_0 /* RTU0 R52_1 */ .long __INT_CTCM_START_1 .long __INT_CTCM_END_1 /* RTU0 R52_2 */ .long __INT_CTCM_START_2 .long __INT_CTCM_END_2 /* RTU0 R52_3 */ .long __INT_CTCM_START_3 .long __INT_CTCM_END_3 /* RTU1 R52_0 */ .long __INT_CTCM_START_0 .long __INT_CTCM_END_0 /* RTU1 R52_1 */ .long __INT_CTCM_START_1 .long __INT_CTCM_END_1 /* RTU1 R52_2 */ .long __INT_CTCM_START_2 .long __INT_CTCM_END_2 /* RTU1 R52_3 */ .long __INT_CTCM_START_3 .long __INT_CTCM_END_3 /* Core TCM data table Tcm_data_ram_start_0 Tcm_data_rom_start_0 Tcm_data_rom_end_0 0 ... */ .section ".tcm_data_table", "a" /* RTU0 R52_0 */ .long __TCM_RAM_DATA_0_START .long __TCM_ROM_DATA_0_START .long __TCM_ROM_DATA_0_END .long 0 /* RTU0 R52_1 */ .long __TCM_RAM_DATA_1_START .long __TCM_ROM_DATA_1_START .long __TCM_ROM_DATA_1_END .long 0 /* RTU0 R52_2 */ .long __TCM_RAM_DATA_2_START .long __TCM_ROM_DATA_2_START .long __TCM_ROM_DATA_2_END .long 0 /* RTU0 R52_3 */ .long __TCM_RAM_DATA_3_START .long __TCM_ROM_DATA_3_START .long __TCM_ROM_DATA_3_END .long 0 /* RTU1 R52_0 */ .long __TCM_RAM_DATA_0_START .long __TCM_ROM_DATA_0_START .long __TCM_ROM_DATA_0_END .long 0 /* RTU1 R52_1 */ .long __TCM_RAM_DATA_1_START .long __TCM_ROM_DATA_1_START .long __TCM_ROM_DATA_1_END .long 0 /* RTU1 R52_2 */ .long __TCM_RAM_DATA_2_START .long __TCM_ROM_DATA_2_START .long __TCM_ROM_DATA_2_END .long 0 /* RTU1 R52_3 */ .long __TCM_RAM_DATA_3_START .long __TCM_ROM_DATA_3_START .long __TCM_ROM_DATA_3_END .long 0

Any help or comments on this topic are greatly appreciated!

Re: init_table, zero_table and other ..._tables

Joey_z — Wed, 25 Mar 2026 10:37:07 GMT

Hi,HiddenSquid

I have received your question, and I will help you to check it.

Joey

Re: init_table, zero_table and other ..._tables

Joey_z — Fri, 27 Mar 2026 03:56:24 GMT

Hi,HiddenSquid

Sorry for the reply late.

The zero_table is used for resetting the .bss . It is recommended that you use SRAM_CTL to initialize the entire RAM, but you still need to use the zero_table. SRAM_CTL initializes "physical RAM", while the .bss reset is a requirement of the C standard. The M33 SMU, as the system management core, handles the starting address / loading address / image size of the R52 Image, and the linking script specifies where the R52 source code should run. The function "xtcm_init" is responsible for initializing the TCM, while "tcm_data_tables" is used to copy specific codes/data from Flash to TCM.

Hope this information can help you.

Joey

topic Re: init_table, zero_table and other ..._tables in S32Z/E

init_table, zero_table and other ..._tables

Re: init_table, zero_table and other ..._tables

Re: init_table, zero_table and other ..._tables