S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi support,
Customer shared that they have an issue where when called sCheck_ExecuteStartupTests() at start up after that it jump to Hard Fault Exception when it executes ECC Test. Could you help to check this point ?
MCU: S32K314
Safety_SW Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi @marcuslim , for each sCheck tests there is mandatory to follow all conditions as described in sCheck UM chapter: L1 CACHE ECC Tests In this case most likely there is wrong placement of the memory section and appropriate MPU setup, this is important for proper execution of this test. For more details please refer to the sCheck UM chapter: Memory Allocation (placement into the sections with correct Cacheable or Non-cacheable MPU attributes is essential) and also you can explore linker file and MPU setup in the SAF Demo example. Kind Regards, Radoslav Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Radoslav,
Cusotmer replaced sCheck_ExecuteRuntimeTests() with sCheck_ExecuteStartupTests() in the NXP example and encountered a similar error.
Could you please clarify exactly where I can check this?
Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi @marcuslim No, you can't use sCheck startup tests by replacing it in a loop dedicated for runtime tests. Startup tests are supposed to be executed only once at the very beginning of application startup process. Moreover, K314 is not supported in SAF Demo Example, so if you have reused some linker file it will most likely not follow memory map for K314 device and need to be updated. SAF is not easy to integrate and requires really to study very well sCheck manual and understand SW safety concept. Kind Regards, Radoslav Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Radoslav,
The customer feedback:
However, we are currently encountering issues related to ECC checking. As you may have noticed, similar ECC check problems also appear in the NXP example.
Integrating the SAF package is quite challenging, and therefore we would appreciate support from NXP specialists in this matter.
Could you please advise on the specific linker-related points or requirements that we need to follow and verify in order to properly integrate ECC checking?
Thank you in advance for your assistance. Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Marcus, all information should be clear from sCheck UM, at least I usually don't have these kind of questions, so SAF team assumed sCheck UM is clear in this matter. Could you ask customer what exactly is not clear from sCheck UM so we can improve? Thanks, Radoslav Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Radoslav,
The customer moved *(.ramcode_no_cacheable) from int_sram_no_cacheable to int_sram and it worked correctly. Feel free to comment if any.
According to Table 55. MemMap sections present in the sCheck module,
the following sections must be placed in specific flash regions:
s32_saf_const_flash_0
→ Code Flash Memory 0
s32_saf_const_flash_1
→ Code Flash Memory 1
s32_saf_const_flash_2
→ Code Flash Memory 2
s32_saf_const_flash_3
→ Code Flash Memory 3
However, in my system I am using A/B Swap, so at any given time only Flash 0 and Flash 1 are active/used by the application.
Placing s32_saf_const_flash_2 and s32_saf_const_flash_3 in the remaining flash blocks may interfere with the unused flash regions (e.g., reserved for the other bank or OTA updates).
My questions are:
Is there a way to configure sCheck so that it only performs tests on Flash 0 and Flash 1?
Or, is there a safe method to test all four flash blocks (Flash 0–3) without affecting the content of the inactive bank used by A/B Swap?
Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Radoslav,
On top of the questions from the last post, Customer shared that after executing the sCheck_ExecuteStartupTests and sCheck_ExecuteRuntimeTests, the system consistently reports the same set of ECC-related errors:
SCHECK_ERR_DCACHE_ECC_CM7_0
SCHECK_ERR_ICACHE_ECC_CM7_0
SCHECK_ERR_ITCM_M7_0_ECC
SCHECK_ERR_DTCM_M7_0_ECC
These errors occur repeatedly and consistently during every test execution.
Could you please support us in investigating and identifying the root cause of this behavior?
Regard,
Marcus
Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi @marcuslim I think there is common root cause. The memory sections need to be placed correctly with cacheable/non-cacheable MPU attributes and that HFNMIENA bit mention in previous post can also cause trouble. Kind Regards, Radoslav Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi @marcuslim , that is probably some coincidence that moving *(.ramcode_no_cacheable) from int_sram_no_cacheable to int_sram worked. I suspect here if customer has set HFNMIENA = 0, that could cause a trouble when exception is triggered. Please could you check what is that value of MPU_CTRL.HFNMIENA If it is zero, following fix has been made for upcoming 1.0.6 release: [ASFT-19327] [sCheck] Arm M7 HFNMIA not supported - NXP JIRA sCheck Flash test can't be reduced just to Flash_0 and Flash_1, but there has been made change for upcoming 1.0.6 release where you don't need to put specififc flash memory sections into the linker file rather it will use configured flash addresses where the content of the address will be not modified, that could solve also the issue for the A/B swap customers. https://jira.sw.nxp.com/browse/ASFT-19738 Kind Regards, Radoslav Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Radoslav,
The customer has tried relocating *(.ramcode_no_cacheable) to int_sram_no_cacheable instead of int_sram , and has also set HFNMIENA = 0. In addition, the MPU has been properly configured to allow code execution from the non-cacheable RAM region.
After further investigation, it is observed that within sCheck_Tcm_RunEccTest , the functions sCheck_Tcm_MemTestEccCorrError and sCheck_Tcm_MemTestUncorrError are executed.
Both of these functions call sCheck_ErrRead(pParams, &result).
However, while sCheck_Tcm_MemTestEccCorrError completes successfully,
sCheck_Tcm_MemTestUncorrError triggers a HardFault when calling sCheck_ErrRead(pParams, &result) (point 1 in the attached image), and the system subsequently gets stuck in a BusFault handler (point 2 in the attached image).
Could you please help investigate this point?
Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi @marcuslim , Sorry I was wrong, correct setting with SAF release you have shall be HFNMIENA = 1 to avoid changing MPU settings in the exception which could further cause some changes in cache flushed afterwards. That would explain why TCM correctable was passing but Uncorrectable not, as it is using exception to test proper reaction. Kind Regards, Radoslav Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Radoslav,
The customer feedback:
>>>>>>>>
After configuring HFNMIENA = 1, I observed that sCheck_ExecuteStartupTests() operates correctly. At this point, I no longer observe any ECC-related errors. I will perform additional stress testing to further verify this behavior.
However, when sCheck_ExecuteRuntimeTests() is invoked and subsequently calls sCheck_Tcm_MemTestUncorrError(), the system triggers a UsageFault exception with the INVSTATE (Invalid State) flag set.
Could you please advise whether there are any design differences or specific usage conditions between sCheck_ExecuteStartupTests() and sCheck_ExecuteRuntimeTests() that could lead to this behavior?
Regards,
Marcus
Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hello @marcuslim , if FPU is enabled, that might indicate protentional issue we need to investigate further. Could you try to disable FPU and perform the test again? What is the result now? With FPU enabled could you within the exception track within Watch window these variables: sCheck_ErrRead_ExceptionContext.bAbortFlag sCheck_DetectedFaults[0] and paste the screenshot again? What is configured reaction for FCCU NCF_2 channel? Kind Regards, Radoslav Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Radoslav,
Please find here the information requested:
Point 1: disable FPU
- same error.
Point 2: Enable FPU
Point 3: FCCU NCF_2 reaction
Regards,
Marcus
Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Marcus,
the latest screenshots show that it generates memory manage fault, not usage fault (as in original post). So, I think we need to clarify which is the exception we are facing.
Please check/share MPU configuration.
Can you check if the exception is cause by "LDRD R0,R1,[R1]\n" instruction from sCheck_Lib_ARMv7M.c or some other instruction?
Kind Regards, Radoslav Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi Radoslav,
Attached is customer's MPU configuration and linker file. He would like us to review them.
Regards,
Marcus Re: S32K3 SAF - sCheck_ExecuteStartupTests run to HardFault Execption Hi @marcuslim , I see they have reused MPU config from RTD example SystemInit(). Please be aware this is just stub from RTD which is not validated and might be not sufficient even for some RTD drivers let alone for SAF. Similarly for the linker file, I can see origins from RTD linker file with additional SAF and SCST memory sections.
For the MPU config I strongly recommend to use RTD Platform plugin to configure MPU. In SAF Demo example we also have example MPU configuration for K344 (not for K314, but it's just about modifying correct memory size for TCM). But it's also just example code (stub) for SAF Demo setup, not validated deliverable. As per AI their MPU config should represent this setup:
Region
RBAR Address
Size
Type / Cache Policy
Shareable
Access
Notes
0
0x00000000
Covers entire address space (RASR = 0x1004003F )
Strongly ordered, no cache
Yes
No Access
Background region blocking everything
1
__INT_ITCM_START
From linker
Normal, no cache
No
RW/RW
ITCM for CM7
2
__ROM_CODE_START
From linker
Normal, WB/WA (inner & outer)
No
RO/RO
Main program flash
3
__ROM_DATA_START
From linker
Normal, WB/WA
Yes
RO/RO
Data flash
4
0x1B000000
8 KB ( 0x160B0019 )
Normal, WB/WA
Yes
RO/RO
UTEST area
5
__INT_DTCM_START
From linker
Normal, no cache
No
RW/RW
DTCM for CM7
6
__INT_SRAM_START
Size from linker ( __RAM_CACHEABLE_SIZE )
Normal, WB/WA
No
RW/RW
Cacheable SRAM (subregions 6 and 7 disabled)
7
__RAM_NO_CACHEABLE_START
From linker
Normal, no cache
Yes
RW/RW
Non‑cacheable RAM region
8
__RAM_SHAREABLE_START
From linker
Normal, no cache
Yes
RW/RW
Shareable RAM
9
0x40000000
6 MB
Strongly ordered, no cache
Yes
RW/RW
AIPS0–2 peripheral space (subregions 6/7 disabled)
10
0x40600000
Disabled for S32K314
—
—
—
AIPS3; active only on S32K39x
11
0x67000000
128 MB
Strongly ordered
Yes
RW/RW
QSPI RX
12
0x68000000
128 MB
Normal, WB/WA
No
RW/RW
QSPI AHB mapped region
13
0xE0000000
Default ARM PPB size
Strongly ordered
Yes
RW/RW
Private Peripheral Bus (SCB, NVIC, etc.)
14
__ROM_CODE_START + 0x400000
0 for S32K314
—
—
—
Additional program flash (only valid for other derivatives)
15
0x44000000
0 for S32K314
—
—
—
ACE region active only on S32K388
and this is MPU config from SAF Demo example for K344:
Briefly comparing these two MPU configs + Linker files can see just: - wrong placement for these memory sections: *(.s32_saf_const_flash_1) *(.s32_saf_const_flash_2) *(.s32_saf_const_flash_3) *(.s32_saf_const_flash_4) *(.s32_saf_const_flash_5) - Can't see Executable attribute for Non-Cacheable SRAM, but this is not required by sCheck, it's probably redundant attribute in SAF example MPU setup - considering customer is running OS, I'd expect some specific MPU setting and memory sections required by the OS and their application (it's just guess, not saying this can be root cause of some issues) Anyway, customer should follow SAF User manuals and RTD manuals, chapter "Memory Allocation" for proper MPU and linker file setup, reusing stubs from NXP examples is not a good practice. And especially when OS running during sCheck tests also following sCheck chapter " Exclusive Areas to be defined in the BSW Scheduler" is requested. Similar Exclusive areas are in eMcem and RTD drivers. Kind Regards, Radoslav
View full article
