S32 SAF library issues

[mohamed_abdelrazek13]

I am currently working on the integration of the SAF Library Premium Version into a Battery Management System (BMS) project, with the target controller being the S32K344. I have encountered several challenges related to the sCheck module and the Mode Selector, and I would greatly appreciate your guidance and assistance in resolving these issues.

Questions regarding the sCheck_Swt0_FuncResetStartupTest:

1. Initialization and Configuration of Timers (STM): In the sCheck documentation, it is mentioned that the STM (System Timer Module) needs to be configured for use by the SAF Library. However, it is recommended not to initialize anything before running sCheck tests. Could you please provide guidance on how to properly initialize and configure the STM for use with the SAF Library while adhering to the recommended best practices?

2. STM Configuration for sCheck_Swt0_FuncResetStartupTest: I am attempting to run the sCheck_Swt0_FuncResetStartupTest. Could you provide specific STM configuration settings that are required to successfully execute this test?

3. Reset Register Cleared by Hardware Initialization: When running the sCheck_Swt0_FuncResetStartupTest, I observed that the reset register is cleared by hardware initialization after the test completes. This causes the test to rerun upon restart, resulting in continuous resets. How can I prevent the reset register from being cleared during hardware initialization after the test execution?

Questions regarding the sCheck_ExecuteStartupTests:

During the Mode Selector process, the sCheck_ExecuteStartupTests run various tests, but some of them fail, causing hard faults. These failures include:

• SCHECK_CMUFC_TEST_RESET_CMU_FC_0
• SCHECK_CRCU_TEST_CRCU_CRC_0
• SCHECK_CACHEL1_ECCTEST_DCACHE_ECC
• SCHECK_TCM_ECCTEST_DTCM_M7_0_ECC
• SCHECK_EDCGASKETS_TEST_EDC_GASKETS_CM7_0
• SCHECK_DMA_ECCTEST_EDMA_TCD_ECC
• SCHECK_FLASH_TEST_FLASH_M7_0_EDMA
• SCHECK_CACHEL1_ECCTEST_ICACHE_ECC
• SCHECK_INTM_TEST_INTM
• SCHECK_TCM_ECCTEST_ITCM_M7_0_ECC
• SCHECK_SRAM_ECCSTARTUPTEST_PRAMC_0_ECC
• SCHECK_SWT_OUTPUTTEST_SWT0
• SCHECK_SWT_COUNTERTEST_SWT0
• SCHECK_XBIC_TEST_XBIC_0

I would appreciate your insights into resolving these failures during the sCheck_ExecuteStartupTests.

Mode Selector Module Issue:

Within the mSel_NvmStorage.c file, the SAF Library initializes the selected mode using MSEL_error. However, when the library reads from NVM, if the previously saved mode is anything other than the normal mode, it does not save anything in NVM. Consequently, the project only runs successfully the first time, after which it returns an error due to the initialized return value being set to E_NOT_OK. Could you provide guidance on a more appropriate solution for this issue?

Additionally, there seems to be a discrepancy between the library's EIM module address (0x40258000UL) and the address mentioned in the data sheet (0x4050C000UL) for the EIM module. Could you clarify this discrepancy and guide on the correct address to use?

I would greatly appreciate your assistance in resolving these issues and providing guidance on how to proceed with the SAF Library integration into my BMS project on the S32K344 controller. Thank you for your support.

[mohamed_abdelrazek13]

I would like to discuss specific challenges encountered during the execution of sCheck_ExecuteStartupTests, particularly in the areas of ECC and CMU testing.

1. CMUFC Test Issue:

   • Upon running the CMUFC test, the controller resets during the restoration of CMU configuration in the sCheck_CmuFc_TestRestore function.
   • A temporary workaround involved commenting out the line "*pDesc->pu32RstBypassReg &= ~(pDesc->u32ResetBypassMask);". However, I seek a more robust solution for this reset issue.

2. ECC Test on Flash:

   • The ECC test on flash results in a hard fault in the sCheck_FlashRead_Cm7 function at the line "u64Data = *pu64FlashPtr;" after injecting a multibit error.
   • I have attempted to handle this hard fault by redirecting to the sCheck handler. Although the recovery is successful, the program counter fails to return from the hard fault handler after recovery.

3. ECC Test on RAM:

   • In the sCheck_ErrRead function (line: pParams->pfErrRead(pParams);), a hard fault occurs during ECC testing in RAM.
   • Similar to the flash test, I attempted recovery through the hard fault handler, but the controller did not resume execution after handling.

4. ECC Safety Mechanism Testing:

   • In the absence of a resolution for the ECC test issues, I explored an alternative approach using the eMcem module to inject ECC faults in flash and RAM.
   • Upon entering the alarm handler, I cleared the fault. Could you confirm if this method is a valid way to test the ECC safety mechanism, or if there are recommended alternatives?

5. SAF Library Version:

   • You mentioned following the steps in the 1.0.3 manual, but my current SAF version is 1.0.2. I have diligently followed the steps outlined in the 1.0.2 manual. Could you provide insights into the differences between versions 1.0.2 and 1.0.3, and where I can access the documentation for version 1.0.3? I couldn't find it on the website.

6. Request for Release Notes and Documentation:

   • Additionally, could you please provide the release notes and documentation for version 1.0.3?

Thank you for your continued support, and I look forward to your guidance on these matters.

Best Regards,
Mohamed abdelrazek

[frantisekdobes]

Questions regarding the sCheck_Swt0_FuncResetStartupTest:

1. Initialization and Configuration of Timers (STM): In the sCheck documentation, it is mentioned that the STM (System Timer Module) needs to be configured for use by the SAF Library. However, it is recommended not to initialize anything before running sCheck tests. Could you please provide guidance on how to properly initialize and configure the STM for use with the SAF Library while adhering to the recommended best practices?
   [NXP] There is an example how to initialize STM provided in SAF sample application (c:\NXP\S32K3_SAF_1.0.3\S32_SAF_Demo\src\main.c):
       /* Initialize the Gpt driver */
       Gpt_Init(NULL_PTR);
       /* Start the Gpt timer - STM0 clk runs at 16MHz -> value 16000000 means 1 second */
       Gpt_StartTimer(GptConf_GptChannelConfiguration_GptChannelConfiguration_0, 16000000U);
       /* Enable the Gpt notification to get the event for acting on configured timer */
       Gpt_EnableNotification(GptConf_GptChannelConfiguration_GptChannelConfiguration_0);
   
   Before running the sCheck tests one of the STM channels must be already initialized and running. During tests the sCheck is reading the STM counter register to know about how much time elapsed - this is used for timeout supervision.
   
   
2. STM Configuration for sCheck_Swt0_FuncResetStartupTest: I am attempting to run the sCheck_Swt0_FuncResetStartupTest. Could you provide specific STM configuration settings that are required to successfully execute this test?
   [NXP] See the answer for previous question, the same applies here.
3. Reset Register Cleared by Hardware Initialization: When running the sCheck_Swt0_FuncResetStartupTest, I observed that the reset register is cleared by hardware initialization after the test completes. This causes the test to rerun upon restart, resulting in continuous resets. How can I prevent the reset register from being cleared during hardware initialization after the test execution?
   [NXP] Yes the sCheck_Swt0_FuncResetStartupTest() function checks the reset flags in MC_RGM FES register. If the flags would be already cleared by application SW previously then this test will not work. To make it work please make sure the reset flags are not cleared by other software before this test function is called.

Questions regarding the sCheck_ExecuteStartupTests:

During the Mode Selector process, the sCheck_ExecuteStartupTests run various tests, but some of them fail, causing hard faults. These failures include:

• SCHECK_CMUFC_TEST_RESET_CMU_FC_0
• SCHECK_CRCU_TEST_CRCU_CRC_0
• SCHECK_CACHEL1_ECCTEST_DCACHE_ECC
• SCHECK_TCM_ECCTEST_DTCM_M7_0_ECC
• SCHECK_EDCGASKETS_TEST_EDC_GASKETS_CM7_0
• SCHECK_DMA_ECCTEST_EDMA_TCD_ECC
• SCHECK_FLASH_TEST_FLASH_M7_0_EDMA
• SCHECK_CACHEL1_ECCTEST_ICACHE_ECC
• SCHECK_INTM_TEST_INTM
• SCHECK_TCM_ECCTEST_ITCM_M7_0_ECC
• SCHECK_SRAM_ECCSTARTUPTEST_PRAMC_0_ECC
• SCHECK_SWT_OUTPUTTEST_SWT0
• SCHECK_SWT_COUNTERTEST_SWT0
• SCHECK_XBIC_TEST_XBIC_0

I would appreciate your insights into resolving these failures during the sCheck_ExecuteStartupTests.
[NXP] During sCheck testing there are bus faults/hard faults expected. To properly handle them it is needed to follow all the steps in sCheck user manual (c:\NXP\S32K3_SAF_1.0.3\eclipse\plugins\sCheck_TS_T40D34M10I3R0\doc\S32K3_SAF_SCHECK_UM.pdf). See section “5 Software Integration”. Especially important to prevent wrong hard faults is to follow there sections “5.3 Memory Allocation”, i.e. it is required to have all the sections properly integrated in linker file (alignment, placement into proper memory ranges) and also correspondingly setup MPU regions for these sections in MPU (Memory Protection Unit) – these include attributes as cacheable/non-cacheable, placement on proper addresses and all others as documented in that section. Also it is needed to implement the functions described in section “3.8 External Reference”, i.e.  function for testing ISRs (Interrupt Service Routines) and testing ESRs (Exception Service Routines). Also check the section “5.8 Conditions, Limitations and Side Effects” documenting confitions to run all tests.

Mode Selector Module Issue:

Within the mSel_NvmStorage.c file, the SAF Library initializes the selected mode using MSEL_error. However, when the library reads from NVM, if the previously saved mode is anything other than the normal mode, it does not save anything in NVM. Consequently, the project only runs successfully the first time, after which it returns an error due to the initialized return value being set to E_NOT_OK. Could you provide guidance on a more appropriate solution for this issue?
[NXP] I’m not able to reproduce this issue. The result of mode selection is either some selected mode or MSEL_NO_OP_AVAILABLE. However, E_NOT_OK is returned by mSel_SelectMode() in case no mode is selected due to some detected failure(s). Those might be the sCheck results you are referring. MSEL_ERROR can be stored into NVM in the situation when MCU NVM has not been previously written or when the NVM Load fails. Then, when no mode is selected, the MSEL_ERROR mode still appears in NVM and is not overwritten by the selected mode. Another possible scenario when mSel_selectMode() returns E_NOT_OK is when the app mode init functions are NULL pointers – for this please check whether the app mode init functions are properly configured.

Additionally, there seems to be a discrepancy between the library's EIM module address (0x40258000UL) and the address mentioned in the data sheet (0x4050C000UL) for the EIM module. Could you clarify this discrepancy and guide on the correct address to use?
[NXP] For S32K344 the correct address to use is 0x40258000UL. This address is properly documented in S32K3xx_memory_map.xlsx attached to HW reference manual (S32K3xxRM_Rev7.pdf), sheet "Peripherals". But I have seen that the address is wrongly documented in S32K3xxRM_Rev7.pdf, section “51.6.1 EIM memory map”.
I checked internally and this issue is already known and it was already reported to HW team to get it fixed in HW reference manual.