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
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
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?
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
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.
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
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?
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
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
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
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?
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
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
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
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
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
Hi Radoslav,
Attached is customer's MPU configuration and linker file. He would like us to review them.
Regards,
Marcus
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