Abnormal wake-up function of S32K312 PIT_RTI

[wuxianlong]

Hi, NXP

I use the RTI module of PIT0 to wake up the S32K312.

I encountered a problem where the RTI cannot wake up the MCU when I do not check the option CM7_0 Under MCU Control. If it is checked, there will be no problem.

I have searched the manual and code but found no association between the "CM7_0 Under MCU Control" option and the RTI. Moreover, this option does not affect other wake-up sources, such as RTC. What could be the reason?

The software version I am using is RTD4.0.0HF02. Below is my configuration code。



Best Regards,
xianlong

[Julián_AragónM]

Hi @wuxianlong,

When something is under the MCU control, the driver has access to the corresponding registers. It is further explained in this community post: Solved: S32K344-StangBy Configuration Options - NXP Community.

Best regards,
Julián

[wuxianlong]

Hi,@Julián_AragónM 

I have studied the link you provided. Just as it is described, CM7_0 Under MCU Control cannot enter WFI, which will cause a timeout. After the timeout, it directly exits without performing any register operations.

Therefore, according to my understanding, CM7_0 Under MCU Control should not be checked, and this option should not affect PIT_RTI.

However, this is inconsistent with the actual test results, so I'm very confused about why this is the case?


Best Regards,
xianlong

[Julián_AragónM]

Hi @wuxianlong,

I've created a project for low power, where both the SW0 and RTI are configured as wake up sources. I've also disabled "CM7_0 under MCU Control", which does not influence whether the MCU can wake up or not; I've only been unable to wake up if "Partition0 Under MCU control" is disabled, which makes sense, since PRTN0 is needed for RTI configuration.

Could you test the application I've attached? (Based in S32DS 3.6, RTD 5.0.0)

Best regards,
Julián

[wuxianlong]

Hi,@Julián_AragónM 

I sincerely appreciate your support. I have tested your demo and found no issues.

After investigating my own application, I discovered that the time interval between Pit_Ip_StartChannel and EXECUTE_WAIT is 30μs. When I increased this delay to 300μs, the problem was resolved.

Subsequently, I tested your RTD 5.0.0 demo and found the time interval to be 300μs, which means my issue was not reproduced.


Could this issue be related to the different clock domains described in the RM manual?



Best Regards，
xianlong

[Julián_AragónM · Accepted solution]

Hi @wuxianlong,

I am honestly not sure if this is the reason. This may have been added in RTD 5.0.0 to avoid this issue specifically but let me confirm with the internal team first.

As for the solution, I suggest either using RTD 5.0.0 or adding the delay before the Standby Entry function.

Best regards,
Julián

[wuxianlong]

Hi,@Julián_AragónM 

Thank you very much for your support. Please let me know if the issue is confirmed.

Best Regards,
xianlong

[Julián_AragónM]

Hi @wuxianlong

The SW team has confirmed that this is a bug in version 4.0.0. The Power_Ip_MC_ME_TriggerPartitionUpdate API does need the timeouts added, but in RTD 4.0.0, user can add timeout check with the CM7_0 Under MCU Control option checked.

Adding the delay or selecting CM7_0 Under MCU Control are the proposed workarounds, for now.

This has been reported, I am waiting on an update for a fix.

Best regards,
Julián

[wuxianlong]

Hi,@Julián_AragónM 

Thank you very much for the information.

I’ve just compared and reviewed the two software versions and confirmed that the ​​Power_Ip_MC_ME_TriggerPartitionUpdate API​​ has added a delay and wait mechanism in ​​RTD 5.0.0​​.

I now have a new question:
Although this issue seems unrelated to ​​RTI (Real-Time Interrupt)​​, why does it only affect ​​RTI​​ while having no impact on ​​RTC (Real-Time Clock)​​ or ​​GPIO wakeup​​?

Best Regards,

xianlong

[Julián_AragónM]

Hi @wuxianlong,

It seems that the root cause is that MCU goes into standby before RTI finishes configurations.

There is this note in S32K3XX RM:

The SW team is working on a fix for this issue. 

Best regards,
Julián

[wuxianlong]

@Julián_AragónM 

Thank you very much for your sharing.

Best Reagrds,
xianlong

[Julián_AragónM]

Hi @wuxianlong

This is also unknown behavior... The SW team is testing the projects I've shared, but there is still no conclusion. If I get a response in a timely manner, I will update this case. If you need an update, you can create a new case and reference this post.

Best regards,
Julián