Hi,
As suggested by "[S32G3/Valeo] RTD MemMap Sections Violations - NXP Community", I am creating this ticket for xxx_MemMap review for LLCE as below (full document attached.)
Please check if below parameter/functions missed to be included in proper memory region after compiled with GHS.
=================================================================
(Can_43_LLCE_TS_T40D11M10I8R0) (Llce_Af_TS_T40D11M10I8R0)
Can_43_LLCE_AFcfg.c:
Llce_Eth2Can_EnabledFormats => data in CAN_43_LLCE_START_SEC_VAR_CLEARED_16_NO_CACHEABLE which is bss section
pLlce_Can_AfBuffer => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
(Can_43_LLCE_TS_T40D11M10I8R0) (Llce_Af_TS_T40D11M10I8R0)
Can_43_LLCE_MAIN_SOC_PBcfg.c: // VariantPostBuild is enabled (MAIN_SOC)
Llce_Rx_Filters_List_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_RxAf_Filters_List_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_Rx_Filters_Ctrl0_PB_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_Rx_Filters_Ctrl2_PB_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_Rx_Filters_Ctrl4_PB_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_Rx_Filters_Ctrl9_PB_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_Rx_Filters_Ctrl15_PB_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_RxAf_Filters_Ctrl0_PB_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_RxAf_Filters_Ctrl5_PB_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_RxAf_Filters_Ctrl9_PB_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
Llce_RxAf_Filters_Ctrl15_PB_MAIN_SOC => data in CAN_43_LLCE_START_SEC_CONFIG_DATA_UNSPECIFIED which is rodata section
(Can_43_LLCE_TS_T40D11M10I8R0) (Llce_Af_TS_T40D11M10I8R0)
Can_Llce:
llce_minihif => Static global variable not inculded in the Can_43_LLCE_MemMap.h
u8Length => Static local variable not inculded in the Can_43_LLCE_MemMap.h
stringBuf => Static local variable not inculded in the Can_43_LLCE_MemMap.h
*****************************************************************************************************************************************************************
Answer: please raise this questions to LLCE team via tag "LLCE" on NXP community
*****************************************************************************************************************************************************************
Hi,
Do you know if fixes are schedule then? if so, when?
Hi,
Extremely late feedback from Valeo regarding your question:
1. When you said: “Llce_Eth2Can_EnabledFormats => data in CAN_43_LLCE_START_SEC_VAR_CLEARED_16_NO_CACHEABLE which is bss section”,
do you say that Llce_Eth2Can_EnabledFormats should be in e.g. .mcal_bss_no_cacheable, but it is actually placed into .bss section?
This variable is initialized by a value of 4 but the variable is within A .bss section not .data section so yes the variable should be in e.g .mcal_data_x.
2. Include global static variable llce_minihif into the appropriate MemMap section. u8Length/ stringBuf are function-static variables and they are not under MemMap control because the MemMap cannot be added inside the body of the function according to SWS_MemMap_00023. If it is required to control them by MemMap section, we can follow the AUTOSAR recommendation : “To force a special memory mapping of a function’s static variable, this variable must be moved to file static scope”.
looks like this variable has been fixed in Can_43_LLCE_TS_T40D11M10I10R0.
3. For the Llce_Rx_Filters_List_
as you can see in the below image there are (static, static const) but all of them are placed in the same section which is .mcal_cont_cfg which is rodata, and this file is generated so it's not up to me to place it in any section.
In the previous/old exchanges you expected no sw updates in next release as there will be no new sw version. Is it still the case?
Hi Cong,
I had summarized the response from our side to customer but no further feedback so far.
I just sent an individual email to our contact to ask for further feedback on LLCE questions you raised.
Will update here if any reply from customer.
Regards,
Richard Chung.
Hi Richard,
Thanks for your updates!
We will have a CD on S32G in Mar-2025, and it is planed in May-2025. There is no plan for the next release after that. So I want to collect the information on the topic, then we can include these implementations in this upcoming release of May-2025.
Please help me with feedback on the questions on my initial response:
1. Do I understand correctly what they say? e.g: When they say: “Llce_Eth2Can_EnabledFormats => data in CAN_43_LLCE_START_SEC_VAR_CLEARED_16_NO_CACHEABLE which is bss section”,
do they say that Llce_Eth2Can_EnabledFormats should be in e.g. .mcal_bss_no_cacheable, but it is actually placed into .bss section?
2. Include global static variable llce_minihif into the appropriate MemMap section. u8Length/ stringBuf are function-static variables and they are not under MemMap control because the MemMap cannot be added inside the body of the function according to SWS_MemMap_00023. If it is required to control them by MemMap section, we can follow the AUTOSAR recommendation : “To force a special memory mapping of a function’s static variable, this variable must be moved to file static scope”. Can you confirm this is a strong request?
3. For the Llce_Rx_Filters_List_
Hi,
As updated on originating ticket about fix expectation, customer will have the code freeze by June.
While there being many components getting involved and need patch, it would be difficult to put them together before June.
So please plan according to your current assumption/resources unless further highlighted by customer.
Regards,
Richard Chung.
Hi Cong,
Sorry for the late update but as you can see on the origin ticket, there is totally no feedback from customer.
I will push for this again but it looks like you can plan according to your evaluation as of current situation.
Regards,
Richard Chung.
Hi Richard,
Do you have any update on the topic?
We need to implement it asap for the March CD on S32G.
Regards,
Cong
For 2. Yes, we created the ticket AF-4950 to log these details. Waiting for the confirmations for the above questions to finalize the ticket details.
Hi,
Thanks for your update.
1. For the Llce_Rx_Filters_List_
2. For the rest, since you mentioned we will revise to ensure the proper section inclusion, do we have a ticket/plan in place to fix them so that we can share with customer?
3. As described on the originating ticket "[S32G3/Valeo] RTD MemMap Sections Violations - NXP Community" FAE is checking with customer on their expectation of this issue correction, will update if any further information here.
Regards,
Richard Chung.
Hi,
First of all, I need to understand the report. When they say: “Llce_Eth2Can_EnabledFormats => data in CAN_43_LLCE_START_SEC_VAR_CLEARED_16_NO_CACHEABLE which is bss section”,
do they say that Llce_Eth2Can_EnabledFormats should be in e.g. .mcal_bss_no_cacheable, but it is actually placed into .bss section?
Following the presumed understanding above, the feedback is:
NXP will:
• Include global static variable llce_minihif into the appropriate MemMap section. u8Length/ stringBuf are function-static variables and they are not under MemMap control because the MemMap cannot be added inside the body of the function according to SWS_MemMap_00023. If it is required to control them by MemMap section, we can follow the AUTOSAR recommendation : “To force a special memory mapping of a function’s static variable, this variable must be moved to file static scope”. Can you confirm this is a strong request?
• Include global static variable definition llce_minihif into the appropriate MemMap section
• Include the declaration of Llce_Eth2Can_EnabledFormats into the corresponding MemMap section. This is most probably the reason for misplacement.
• Include the declaration of pLlce_Can_AfBuffer into the corresponding MemMap section and double check whether the current MemMap section is appropriate .
• Llce_Rx_Filters_List_
Hi,
Is there any update?
Regards,
Richard Chung.