Inquiry Regarding ICU Timestamp Function on S32K311

[NewbieNerd]

Dear S32K Team,

Hello.

We are currently in the process of configuring the ICU Timestamp function on the S32K311 and would like to make an inquiry regarding this matter.

At present, the ICU is using eMIOS1 channel 9 (eMIOS1_CH9). However, we have observed abnormal behavior where the IRQ is triggered, on average, within approximately 1 ms after configuration and execution. We would like to confirm whether this issue is due to a configuration error.

Please refer to the attached image. We have reviewed the S32K311 Reference Manual, but were unable to find a detailed explanation regarding the ICU Timestamp mode. Therefore, we would appreciate it if you could provide any relevant documentation or advice.

Thank you for your review, and we look forward to your response.

Best regards,

[danielmartynek]

Hello @NewbieNerd,

Can you please specify the revision of the RTD?

Each eMIOS interrupt vector has 4 eMIOS channels, so it can be the other channels that trigger that.

Anyway, the ICU driver provides two notifications, one for the overflow and one for time_stamps.

If you monitor just the notifications, do you see the abnormality?

Regards,

Daniel

[NewbieNerd]

Thank you for your response.
The RTD revision is R21-11_3.0.0_P07.
Currently, only eMIOS_1_ch9 is used in the ICU; other eMIOS1 channels are not in use.
The interrupt vector being used is eMIOS_1_11_8 (072).

The same issue occurs even when the overflow notification option is disabled.
The values read from the continuously triggered notifications are identical.

Looking at the memory stack, the event is called twice in a very short time — once in Emios_Icu_Ip_ReportEvents and once in Emios_Icu_Ip_TimestampHandler.

[danielmartynek]

Hello @NewbieNerd,

This is a 2 year old RTD.

I haven't found any report that would mention such an issue.

Can you reproduce it with the current RTD 6.0.0?

Or can you share the compiled .elf file along with the source code?

Please double-check:

1. Compiler options, it should be configured as per the release notes.

2. System clock configuration, it should match precisely one of the clock options listed in the RM. Otherwise, the functionality of the MCU cannot be guaranteed.

Regards,

Daniel

[NewbieNerd]

Thank you for your response.

Due to security policy, we regret to inform you that we are unable to provide the requested file.

The issue has been resolved through a workaround; however, the root cause has not yet been clearly identified.
The issue and resolution process are as follows:

After the notification was triggered in Icu_ReportEvents, the same notification was triggered once again in TimestampHandler.
The values measured in both notifications were identical.

Subsequently, after disabling OverflowReport and applying the Filter Bypass setting,
the symptom where the same notification was triggered twice within 1ms no longer occurred,
and only the intended single notification was observed.

At this point, we are unsure how to interpret this behavior.
We would appreciate your guidance on whether this symptom suggests a structural or configuration-related issue.

[danielmartynek · Accepted solution]

Hello @NewbieNerd,

I don't see any issue in the configuration you posted here.

I understand you cannot share the whole project here, but If you could share all the ICU related APIs as you call them, I can review it as well.

Could you test it separately with the filter enabled, I think this could be the root cause.

Can you monitor the input signal with an oscilloscope?

[NewbieNerd]

Thank you for your response.

After reviewing the issue from multiple angles, we suspect that the behavior is caused by the overflowNotify setting.
The system works correctly regardless of whether filter_bypass is used or the filter is set between 02 and 16.

We truly appreciate your support and the effort you put into helping us identify the issue.

Best Regard

[NewbieNerd]

For reference, the input source to the ICU is a 64 Hz signal with a 50% duty cycle.