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
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
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 = 0x20C80000eMCEM 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
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?
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.
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
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?
Hi, sorry – you're absolutely right, my mistake. I got confused; I meant the CMU_FC0 test – with interrupt vector 84.
I know that for the sCheck INTM/CMU_FC0, everything is prepared according to the sCheck documentation.
The interrupt is configured correctly, and the Install_ISR function has been implemented properly.
My concern is about the Clock_IP_CMU_ClockFail function itself.
When the MPU is configured to catch NULL_PTR accesses, the Clock_IP_CMU_ClockFail function, during the INTM and CMU_FC0 tests, accesses an array where positions 1 and 2 are defined as NULL_PTR – which causes an OS_memory_protection error.
This happens because the for loop tries to read values from the IER fields, which are defined as NULL_PTR.
