Capturing CPS with CRANK, mpc5775e Hi, I am using the NXP eTPU CRANK function with a 36-2 crank wheel. The CPS signal is generated with an increasing RPM (acceleration profile). The CRANK parameters (gap_ratio, win_ratio_normal, win_ratio_across_gap, win_ratio_after_gap, and win_ratio_after_timeout) are calculated using the Excel sheet provided with the Function Selector. After the engine position reaches FS_ETPU_ENG_POS_PRE_FULL_SYNC, I call fs_etpu_crank_set_sync() once to synchronize TCR2. I verified that synchronization is applied correctly by checking the TCR2 value before and after the call; it changes by the expected amount. To calculate RPM, after the CRANK state changes from FS_ETPU_CRANK_TOOTH_AFTER_GAP, I copy the tooth period log using fs_etpu_crank_copy_tooth_period_log(), calculate the average tooth period, and then calculate RPM. The first RPM value is calculated correctly. However, after one or a few revolutions, the CRANK function reports FS_ETPU_CRANK_ERR_TIMEOUT and FS_ETPU_CRANK_ERR_STALL. Once these errors occur, synchronization is lost and I can no longer calculate RPM. The confusing part is that if I reset the debugger and run the application again with exactly the same CPS signal and configuration, sometimes it continues running correctly and I can capture RPM values for a much longer time, while other times the errors appear almost immediately. Because the input signal and configuration are unchanged, I do not understand why the behavior is inconsistent. Could this be related to the window ratio parameters? If so, which parameter should I adjust first for an accelerating crank signal (win_ratio_normal, win_ratio_after_timeout, gap_ratio, etc.)? Is there a recommended procedure for tuning these parameters for rapidly accelerating signals? Thanks! Re: Capturing CPS with CRANK, mpc5775e Hello,
My current assessment is that the most likely causes are either window margins that are too tight for the applied acceleration profile, or an incomplete reinitialization that results in different starting conditions after a debugger reset. At this point, I would not consider the root cause confirmed. Based on the information provided, the CRANK function initially achieves synchronization and produces valid RPM values, indicating that the basic configuration is functional. The issue appears later, when the function loses timing acceptance and eventually reports FS_ETPU_CRANK_ERR_TIMEOUT and FS_ETPU_CRANK_ERR_STALL.
To efficiently narrow down the root cause, I would start with two simple experiments:
Increase the relevant window ratios and observe whether the timeout/stall condition is delayed or eliminated.
Repeat the test with a reduced acceleration slope and compare the behavior to the original profile.
If the issue improves with wider windows or a slower acceleration ramp, this would strongly suggest that the failure is related to timing margins rather than a fundamental configuration issue.
Best regards,
Peter
查看全文
