I'm working on MPC5554. I try to read period and direction from a hall sensor with Quadrature Decoder (QD) eTPU Function. I can read direction there is no problem. Also I can read 1 Hz to 30 KHz signals. But if I give 0.9Hz, 0.8Hz, ... 0.1Hz which are under the 1 Hz, I can't read correct frequency. In this situation there is a ossilacition.
I use tpu_fqd_init() to init, I use fs_etpu_qd_get_period() function to read period and I use fs_etpu_qd_get_direction() function to get direction.
I simulated hall sensor signals(2 signals which are %50 duty and 90° phase shift) and I read period from fs_etpu_qd_get_period();
Signals--------Period
1 Hz --------- 8 000 346
5 Hz --------- 1 600 070
1000 Hz ---- 8000
The above examples are correct. But the below example are not OK which are under 1 Hz.
Signals--------Period
0,9 Hz --- 501 114
0,8 Hz --- 1611540
0,5 Hz --- 7612084
0,1 Hz --- 4469624
How can read under 1 Hz, how can detect zero speed from hall sensor?
It appears the problem is that the period measurement is overflowing at low frequencies of less than 1Hz. The TCR1 counter is being used for timing in your configuration, and looks to be running at 8MHz, which given its 24-bit range, means that potential overflow issues arise if a timing period approaches or exceeds 1 second. Your options to address this are to configure the TCR1 counter to a slower frequency, if your other eTPU applications can support that. Or, if the TCR2 counter is not otherwise being used, configure TCR2 to run at a lower frequency and have your QD function use that counter for its time base.
I use 16 MHz TCR1 counter. As I understood, with 24-bit range and 16 MHz counter, I must read until 0,4768 Hz but I couldn't. I can read correct until 0,96 hz. Below 0,96 Hz there is a problem. For example I read 245 Hz when signals are 0,95 Hz.
I use this equaliton for calculate the frequnecy.
Frequency = (float_t)etpu_a_tcr1_freq / (float_t)(fs_etpu_qd_get_period ( channel_no ) * 2);
In the eTPU code the period is calculated as follows:
period = (erta - last_leading_edge)>>1; // Period between two leading edges divided by 2
where 'erta' holds the timestamp (TCR1 in your case) of the current leading edge, while 'last_leading_edge' is the previous leading edge, both 24-bit values. Thus if the time between leading edges exceeds 2^24-1 counts (1.05 seconds in your configuration) the calculation overflows and gets an incorrect result.
So for your case of 0.95Hz, the correct value for 'erta - last_leading_edge' would be 16842105 counts, but this exceeds the 24-bit range and so instead the calculated value is 64889 after overflow (32444 after divide by 2), which per your frequency calculation code yields ~246Hz. Simulation case of this attached.
You will need to use a slower time base to support measurement of frequencies below ~0.96Hz.
Although I mentioned two possibilities to support low frequencies (reduce TCR1 timer frequency or switch to TCR2), there is also a third - modify the eTPU code to support longer period measurement. I suspect such a solution is not of interest to you, but perhaps it is for someone in the community. See attached code package which contains an enhanced QD that supports 32-bit period collection and a few other minor improvements.
