MPC5744P etimer frequency measurement with cascade counter

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC5744P etimer frequency measurement with cascade counter

844 Views
YL005
Contributor III

Hi

I implement frequency measurement function by using etimer module with cascade counter

The calculated frequency goes wrong sometime with the below CAPT1/CAPT2 counter
The second element counter in capture_ch0 is obviously full and starts counting from zero.
So the second element in capture_ch1 should be 1 greater than the others, but the picture below shows that the fourth element in capture_ch1 is also 1 greater than others.

YL005_0-1700127862012.png

From the reference manual of MPC5744P I think all related counters should be frozen in the Hold register.I'm wondering why the counter I read looks like this.

YL005_1-1700128602618.png

The SDK version I use is as follows. If I need to provide the SDK configuration or frequency calculation method, I can provide it.

** Processor : MPC5744P_144
** Component : etimer
** Version : Component SDK_S32_PA_11, Driver 01.00, CPU db: 3.00.000
** Repository : SDK_S32_PA_11

Tags (3)
0 Kudos
8 Replies

793 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

a meaning of your buffer should be below, I think, at least from the way CAPT registers are read out

PetrS_1-1700573411632.png

So I think 32bit values for consecutive edges increments, if this gives correct result I cannot comment.

BR, Petr

 

0 Kudos

784 Views
YL005
Contributor III

Hi,

I think the value of 4.edge are weird.

If the counter in capture ch0 is less than 65535, why the 4th counter in capture ch1 is 1148 rather than 1147?

0 Kudos

767 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

3rd edge value is also 1148 so 4th should not be lower, but seems 2nd is lower then 1st.
You can try to stop capture logic after 4 edges are get and start it again after reading/calculation is done.
What is the signal measured and thus expected values/differences between edges? 

BR, Petr

0 Kudos

717 Views
YL005
Contributor III

Hi Petr,

The signal under test is usually between 100Hz to 1kHz with 50% duty. Therefore, I'd expect the value between each eage should be the same. Most of time the captured values ​​are correct, but sometimes an exception occurs like the situation mentioned above.

0 Kudos

711 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

ok, so if frequency is not changed during single measurement, then captured values should be correct.
Not sure what to comment more, I would recommend to have latest SDK. Maybe try to add DMA to read results and see difference.
NonSDK code is posted on 
https://community.nxp.com/docs/DOC-104285
https://community.nxp.com/docs/DOC-330571

BR, Petr

0 Kudos

686 Views
YL005
Contributor III

Hi,

Thanks for your suggestion, I will check if the latest SDK can solve this problem.

I would like to ask if there are any SDK-related examples, because I have already seen non-SDK examples, but I have some questions about configuring DMA in the SDK.

0 Kudos

677 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

I am not aware of SDK example.

BR, Petr

0 Kudos

836 Views
YL005
Contributor III

The input signal is measurement from F[0] (eTimer_0 Channel 2)

I cascade the eTimer_0 channel 1 and channel 2, the register of eTimer_0 is as attached files.

YL005_0-1700130401947.png

The code to get the counter is as below.

YL005_3-1700130768943.png

 

 

 

0 Kudos