S32K3+RTD400+SPD 1.0.4 link file

[Neo1096]

I encountered some issues regarding link files when using SPD104. Currently, I am using iar version 9.50.2. The icf file generated when converting from S32DS to iar does not include SPD-related content. I refer to the section about eMcem_MemMap in the SPD104 manual. Some segment allocations were added to the icf file, but some problems were still encountered.

The most frequently encountered error is this

Error[Lp005]: placement includes a mix of sections with content (example "rw data section .s32_saf_bss in eMcem.o symbols: [eMcem_DriverState]") [suitable for placement in ROM] and sections without content (example "zi section .bss in abs.o symbols: [abs_output]") [suitable for placement in RAM]

From the code, for example, there is the following code in eMcem_MemMap.h

#ifdef EMCEM_START_SEC_VAR_ZERO_INIT_UNSPECIFIED

/ * *

* @file eMcem_MemMap.h

* @violates @ref eMcem_MemMap_h_REF_1

* /

#undef EMCEM_START_SEC_VAR_ZERO_INIT_UNSPECIFIED

/ * *

* @file eMcem_MemMap.h

* @violates @ref eMcem_MemMap_h_REF_1

* /

#undef MEMMAP_ERROR

#pragma ghs section bss=".s32_saf_bss"

#endif

According to the understanding in the manual, the.s32_saf_bss segment here should be a segment placed in RAM, but in eMcem.c, there is the following code

#define EMCEM_START_SEC_VAR_ZERO_INIT_UNSPECIFIED

/* @violates @ref eMcem_c_REF_0410 */

/* @violates @ref eMcem_c_REF_2001 */

#include "eMcem_MemMap.h"

/ * *

* @brief Driver state.

* @details The eMCEM driver changes state during start-up or runtime from EMCEM_S_UINIT to EMCEM_S_INITIALIZED.

* If the configuration lock type is set to HARD_LOCK, driver locks its configuration

* and changes its state to EMCEM_S_LOCKED.

* /

eMcem_StateType eMcem_DriverState = EMCEM_S_UNINIT;

#define EMCEM_STOP_SEC_VAR_ZERO_INIT_UNSPECIFIED

In the code, eMcem_DriverState is explicitly assigned a value. Even though the assignment here is 0, according to the rule, it should be placed in the data section

I can configure the compiler to forcibly correct the segment allocation logic of variables: move the explicitly zero-initialized variables that should belong to "no content" from the.data segment (with content) to the.bSS segment (no content), making it comply with the requirement in the linker script that only "no content segments" can be placed in the RAM area, thereby resolving the conflict of mixed placement. But I don't think this is a solution to the problem from the root

Is there a more reasonable solution to this problem?

[danielmartynek]

Hi @Neo1096,

Can you use the linker file from this thread?

https://community.nxp.com/t5/S32K/S32K3-SPD-DMA/m-p/2139734

BR, Daniel