The program did not enter an interrupt during execution, and pit_notification was not called.
Software environment: S32DS 3.6.0 RTD 6.0.0
Could different software versions be a factor?
Hi @Finnc
Currently, I do not have access to an S32K311 board. However, I tested the same configuration and code on an FRDM-A-S32K312, and I was able to confirm that PitNotification is called and the counter increments as expected.
Could you set a breakpoint inside the notification function to verify whether it is being called?
BR, VaneB
When running at full speed, pit_notification is not triggered , and the PitCount value remains at 0. The register parameters when paused are shown in the figure.
Could this be related to the clock configuration? The configuration is as follows: 
Hi @Finnc
I was able to test your code on my side using an S32K311EVB, and everything is working as expected.
To help rule out any issues related to your custom hardware, could you please try switching the clock source to FIRC and see if there is any change in the behavior?
Hi @Finnc
As observed in your code, the counter only increments when PitNotification is called. This indicates that the PIT interrupt is being triggered correctly.
For a simpler and more visible test, you can use printf to output the counter value inside the PitNotification function. If you are able to see the printed values, this will further confirm that the interrupt is being executed as expected.
For example, I implemented it as follows:
Hi @Finnc
It seems that the problem might not be software related; it may instead be associated with your custom board. Do you have access to another board with an S32K311 device that you could use to run the same test for comparison?
Hi @Finnc
Since the code is working as expected on my side with both the FRDM-A-S32K312 and the S32K31XEVB-Q100, and also on your side using the S32K312, it seems that the issue might not be software-related.
Based on the behavior you described, this could potentially be related to the hardware. However, it is difficult to determine the exact root cause without further analysis. It might be helpful to take a look at the S32K31XEVB-Q100 schematic and the Hardware Design Guidelines for S32K3xx Microcontrollers file (included in the S32K3 General Purpose Hardware Design Package) to compare your custom board against the recommended design practices.
If you think the issue could be related to the MCU itself, please contact your NXP representative or the distributor from whom the parts were purchased for further assistance.
Hi @Finnc
The original program was used, with an LED blinking added to the interrupt. The problem has now been resolved. It was because the J-Link programmer's reset pin was connected to NTRST. Replacing it with SRST resolved the issue and the program ran normally. What's the difference between these two pins? Is it necessary to connect it to SRST? Do all chips require this pin connection?
