S32KのトピックRe: sCheck Test CMU_FM, ISR problem

sCheck Test CMU_FM, ISR problem

Marekp — Tue, 15 Apr 2025 07:40:13 GMT

Hi, I have an issue with the CMU_FM_1 and CMU_FM_2 tests.
The test has been configured in sCheck as a StartUp test.

Additionally, when the test starts, the CMU_FC test is executed as well.

The CMU_FC test is enabled.
An interrupt is installed for CMU_FC with Interrupt ID = 84.
The interrupt for the CMU_FC test is triggered. The ISR(Mcu_Cmu_ClockFail_IRQHandler) from Clock_Ip_Irq.c is executed, which calls the callback function CMU_ClockFailureNotification.
The CMU_FC test finishes successfully.
The test for CMU_FM starts with Interrupt ID = 85.
No interrupt occurs, and the microcontroller resets according to the configuration.

"Software must ensure that CMU1 interrupt is serviced within POR_WDG timeout. In absence of CMU1 interrupt servicing, the POR_WDG detects this as an FIRC failure and initiates a POR recovery. - Chapter 57 Clock Monitoring Unit – Frequency Meter (CMU_FM)"
How should the interrupt for CMU_FM be handled?
I cannot find the name of the ISR corresponding to CMU_FM_1 or CMU_FM_2 in the codebase.

Re: sCheck Test CMU_FM, ISR problem

RadoslavB — Wed, 16 Apr 2025 12:13:53 GMT

Hi Marek,

are you using EB Tresos MCU plugin?
The MCU plugin supports now only CMU_FC, so there is only this notification:

For CMU_FM interrupt handlers you can register them via Platform plugin like this:

This is not very well documented in RM Interrupt Map XLS either:

CMU_0 is CMU_FC_0
CMU_1 is CMU_FM_1
CMU_2 is CMU_FM_2

So please register the CMU_FM handlers and do the interrupt redirecting to sCheck handler like for example (snippet from SAF Demo example, see the example for more details if needed):

Kind Regards,
Radoslav

Re: sCheck Test CMU_FM, ISR problem

Marekp — Thu, 17 Apr 2025 12:14:47 GMT

Thank you for the guidance. I’m using AUTOSAR and managed to configure the interrupt successfully in DaVinci. The StartUp tests for CMU_FC and CMU_FM complete with a positive result. HOWEVER, the RunTime and ShutDown tests for CMU_FM are failing. The processor frequency is 160 MHz. When the StartUp tests are skipped and only the RunTime tests are executed, the result for CMU_FM is still a failure. This situation occurs consistently, even when CMU_FM tests are not enabled for the StartUp phase.
CPU- S32k322

Re: sCheck Test CMU_FM, ISR problem

Marekp — Thu, 17 Apr 2025 12:32:40 GMT

Parameters:

FXOSC Frequency- 2.4E7

FIRC Frequency- 4.8E7

Clock Mux0 Divider2 Frequency (AIPS_SLOW_CLK) (dynamic range) - 4.0E7

Re: sCheck Test CMU_FM, ISR problem

RadoslavB — Thu, 17 Apr 2025 13:25:20 GMT

Hi Marek,

difference between startup and runtime/shutdown is that startup is configuring CMU on its own, but runtime/shutdown rely on CMU configuration from customer app.

From the screenshot it seems that CMU_FM is not configured?
You need to setup CMU_FM via registers according to RM + see notes in sCheck UM - chapter: CMU Tests, especially configure REF_CNT at least 3x above the minimum REF_CNT.
You can explore CMU_FM setting during startup test and configure in a same way for runtime.

Kind Regards,
Radoslav

Re: sCheck Test CMU_FM, ISR problem

Marekp — Fri, 18 Apr 2025 12:24:27 GMT

Thank you for your guidance. The CMU_FM1 test is now working correctly in both runtime and shutdown phases.
However, I still have an issue with the CMU_FM2 test — it cannot complete during runtime and shutdown.
The interrupt associated with this test (InterruptID = 86) is being continuously triggered,
and the test cannot finish because pContext != NULL_PTR.
As a result, the watchdog cannot be refreshed and a system reset occurs.
Should CMU_FM2 perform any specific action after the test is completed?
This does not seem entirely possible, since the InstallIsr function installed sCheck_CmuFm_TestIsr as the handler,
and the interrupt continues to be triggered indefinitely.

could You help ?

Re: sCheck Test CMU_FM, ISR problem

RadoslavB — Tue, 22 Apr 2025 07:53:14 GMT

Hi Marek,

can you do screenshot again from sCheck General Tab to see FXOSC clk and STM clk and then screenshot from RTD how exactly is configured STM instance used by sCheck? These settings must be equal.

And please try to set breakpoint into function sCheck_CmuFm_RunTest() to this line:
pArgs->u32Signature = SCHECK_INTERNAL_ERROR;
and confirm if this line is reached.

Also screenshot how CMU_FM2 registers looks like before the test is executed.

Kind Regards,
Radoslav

Re: sCheck Test CMU_FM, ISR problem

Marekp — Mon, 28 Apr 2025 07:34:54 GMT

Hi Radoslav,
Your advice turned out to be very helpful regarding the CMU_FM topic. Thank you very much for your support — we managed to resolve the issue with that test.
However, enabling additional tests has brought up new problems:

The Runtime test for FCCU_NCF is reporting an error —
FCCU signature = 0x20C80000
eMCEM is not initialized.
I am basing my implementation on the examples provided in the DEMO.

Here are the values from the sCheck driver configuration:
- STM Frequency (Hz) (dynamic range) – 40000000
- FXOSC Frequency (Hz) (dynamic range) – 24000000
- FIRC Frequency (Hz) – 48000000
- CMU Bus Clock Frequency (Hz) (dynamic range) – 16000000
  
  And clock configuration

Re: sCheck Test CMU_FM, ISR problem

RadoslavB — Wed, 30 Apr 2025 08:06:23 GMT

Hi,

FCCU_NCF test signature 0x20C80000 represents correct test execution, so sCheck_ErrorCodeType shuld return E_OK. Where do you see a problem?

BTW this test is not possible to configure for runtime phase, only startup or shutdown is possible.

If it's executed via sCheck_ExecuteStartupTests() you don't need to have eMcem_Init() done, but for shutdown it is required.
One condition is to not configure FCCU with HARD LOCK setting.

Kind Regards,
Radoslav

Re: sCheck Test CMU_FM, ISR problem

Marekp — Wed, 30 Apr 2025 08:40:15 GMT

Hello Radoslav
Yes of course FCCU_NCF test is exucuted on startup test.
Signature which is returned from function sCheck_ExecuteSimpleTestBatch() is equal
0x20C80000

But function sCheck_GetTestBatchResult() return SCHECK_TEST_ERROR in IF

FCCU is of course NO LOCK

Where to look for the cause of the error?

Re: sCheck Test CMU_FM, ISR problem

RadoslavB — Wed, 30 Apr 2025 09:29:34 GMT

Hi,

this is strange, didn't you modify generated sCheck cfg file?
You can try to generate cfg files again - it looks like expected signature and accumulated doesn't fit, but in a same time the signature value you posted imply that all tests passed OK so it should fit.

Could you provide list of all sCheck startup test you are executing?

Kind Regards,
Radoslav

Re: sCheck Test CMU_FM, ISR problem

Marekp — Wed, 30 Apr 2025 09:58:23 GMT

Hello

"This is strange, didn't you modify the generated sCheck configuration file?"– No, the sCheck_Cfg.c files have not been modified.

The generated signature for the FCCU_NCF test is: 0xDF2F0000UL

For the purpose of this test, only the FCCU_NCF test is executed.

As an example, I enabled only the following startup tests:CMU_FC_0,CMU_FC_3,CMU_FC_4,CMU_FM_1,CMU_FM_2

The generated signature was: 0x27C00000UL
And the tests completed successfully.

So, does Tresos generate incorrect cfg files for the FCCU test?

Re: sCheck Test CMU_FM, ISR problem

RadoslavB — Wed, 30 Apr 2025 14:37:26 GMT

Hi,

please could you try to modify file
\SafetyBase_TS_T40D34M10I4R0\resource\CORTEXM_S32K3XX_s32k322_hdqfp172.properties
or CORTEXM_S32K3XX_s32k322_hdqfp100.properties (depends on what you have selected in Resource module)
find line with text:
sCheck.Fccu_Ncf_Test.FCCU_NCF.Signature:0x20D10000
and change to
sCheck.Fccu_Ncf_Test.FCCU_NCF.Signature:0x20D80000

Regenerate the project and rebuild project and try the NCF test again please.

Kind Regards,
Radoslav

Re: sCheck Test CMU_FM, ISR problem

Marekp — Mon, 05 May 2025 07:04:56 GMT

Hi Radoslav,

Sorry for the late reply.

Following your recommendations, I updated the signatures in the file:
"SafetyBase_TS_T40D34M10I5R0\resource\CORTEXM_S32K3XX_s32k322_hdqfp100.properties"

Unfortunately, the issue still persists. The FCCU tests return the result: SCHECK_TEST_ERROR
The result of the XOR operation in line 305 in function sCheck_GetTestBatchResult(...)

(((∼0x20C80000)+1UL)^0xDF280000)=0x00100000
I also checked the FCCU (scheck) tests — none of them report any errors, so the problem is most likely related to the generated signature.

Re: sCheck Test CMU_FM, ISR problem

RadoslavB — Mon, 05 May 2025 09:06:50 GMT

Hi,

Sorry for misleading info, correct signature is 0x20C8_0000.
So, if you can change resource file again with this value, the test should pass.

if you can confirm we will create bug ticket for this.

Kind Regards,
Radoslav

Re: sCheck Test CMU_FM, ISR problem

Marekp — Mon, 05 May 2025 12:50:21 GMT

Hi
thank you very much for your help — the solution you suggested works perfectly
How is the situation regarding the SAF library update?
Is there a plan for a new SAF package to be generated by your team with these changes?

Re: sCheck Test CMU_FM, ISR problem

RadoslavB — Mon, 05 May 2025 13:14:52 GMT

Hi,

thanks for confirmation, we have created bugticket for this.
Another SAF K3 release is planned for November 2025 unless it will be requested earlier.

Kind Regards,
Radoslav

Re: sCheck Test CMU_FM, ISR problem

Marekp — Tue, 06 May 2025 12:35:28 GMT

Hi Radoslav,
I have one more issue related to the SWT_0 test — how is this test supposed to be handled?

The problem is that if we use the callback mechanism through the SWT driver, the interrupt flag is cleared within the driver's interrupt handler, and only then is the callback invoked.
Clearing the interrupt flag causes the SWT test to fail.
Since modifying the RTD source code is forbidden, should I configure my own interrupt handler for this test — separate from the one provided by the driver?

This question is realated with Re: SAF sCheck SWT_0 and FCCU_NCF test, s32k322 - NXP Community

Re: sCheck Test CMU_FM, ISR problem

RadoslavB — Tue, 06 May 2025 16:29:46 GMT

Hi,

yes, in this case there is a conflict with ISR coming from RTD driver which handles the HW flags needed for sCheck.

We are internally investigating this use case, but as you should not modify RTD code you might try to temporarily redirect interrupt handler for sCheck purpose right in the sCheck_InstallTestIsr() e.g.

And then when calling sCheck_UninstallTestIsr() redirect back to original ISR.

Or if your OS doesn't allow dynamic ISR registration during runtime, alternative approach is to prepare copy of Interrupt Vector Table (with change only for sCheck ISR handler) and temporarily change VTOR.

Kind Regards,
Radoslav

Re: sCheck Test CMU_FM, ISR problem

Marekp — Thu, 08 May 2025 05:44:02 GMT

Hi, just to follow up on the topic —
after enabling the MPU for NULL_PTR checking, I’m still experiencing an issue with the CMU_FC and INTM test, specifically in the FOR loop within a function.
During the second increment of the IndexCmu variable, the code attempts to access the IER register, but its value is NULL_PTR.
This happens because on the S32K322 processor, the Clock_Ip_apxCmu[CLOCK_IP_CMU_INSTANCES_ARRAY_SIZE] array only contains valid entries at indexes 0, 3, 4, and 5, while indexes 1 and 2 are defined as NULL_PTR

Shouldn't there be an additional check to verify whether CmuIsrValue and CmuIerValue are not NULL_PTR?