S32K322 Moving BSS Section from SRAM to DTCM

[S_Kira]

Hello, 

i have attached my linker and startup code.

Need help with this

1. We want to use only core 0 and need to disable core 1.

2. Our Data (31K) + BSS (56K) section exceeds 87KB. Can you provide a linker file, startup.c, startup.s, and system.c to accommodate this, with MPU enabled in the system.c file , please include the initialization sequence for data and BSS in startup.s and startup.c. Note that we don't intend to use core 1, and we can exclude memory allocation for core 1."

[S_Kira]

Also, I have attached the latest linker file that accommodates our data and BSS sections. However, with this linker, I had to disable the MPU, and the code will work randomly. Sometimes it functions correctly, but other times it leads to a hard fault.

[davidtosenovjan]

We don’t have example code for this specific configuration, but I can offer example code for using DTCM/ITCM memories in the project:

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-Siul2-Port-Ip-Example-S32K344-ITCM-DTCM-S32...

Modification has been done in following files:

- main.c

- startup_cm7.s

- linker_flash_s32k344.ld

Then modifying of linker command file in order to put .bss section to DTCM should not be difficult.

Hope it helps

[S_Kira]

Update:

1. Modified memory size in powers of 2 to enable MPU.
2. Enabled the MPU.
3. Introduced a new section, dtcm_bss, in the dtcm memory area to accommodate the BSS.
4. Updated __INT_DTCM_END with the length of the dtcm_bss section.
5. Adjusted __RAM_SHAREABLE_SIZE, __RAM_NO_CACHEABLE_SIZE, and __RAM_CACHEABLE_SIZE based on their size in powers of 2.
6. Disabled the NO_INIT_STANDBY_REGION code to avoid skipping ECC initialization of standby RAM area (preventing hard fault errors triggered from SRAM_LOOP).
7. Updated the linker file for the core 1 project.
8. Assigned 48 KB SRAM to Core 0 and 16 KB to Core 1.

Results:

1. Ran the CORE 0 project without exceptions in debug mode, and reset works without throwing exceptions in the debug window.
2. However, during a power-on reset without the debugger, the program doesn't execute. Speculation: The debugger may be holding Core 1 in the coreloop, causing Core 0 to execute in debug mode.
3. The Core 1 project functions only during the debugger flash cycle. if a reset is given in the debug window it will throw a hard fault exception. This applies to the default generated core 1  project (without any change in the linker file and start files in both cores )

Exception Details: UsageFault - The processor attempted to execute an undefined instruction. HardFault - A fault has been escalated to a hard fault.

Attached debugger output latest linker and startup files for both cores.