Timer Input Module (TIM) - TC3777

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins
Hello,

I am facing below issue with reading PWM Freq/Duty Cycle. Can you please provide some help ?

I have configured my TIM channel in "PWM Measurement Mode - Continuous". I am checking for NEWVAL flag every 1ms to determine if there is any new value and then read the GPR0/GPR1 registers to get freq/Duty Cycle.

PWM input signal is connected to a sensor (Freq range is 0-20Khz). When the PWM frequency from my sensor is constants (example 2Khz), I get correct value from these registers.
When PWM frequency from my sensor changes ex: 2Khz to 5Khz, then I get some bad value ~700Khz and after some time the PWM reads correct value 5Khz.

Any thoughts on why I am seeing this intermittent bad value ? Is there any way I can filter out this bad value in the PWM peripheral ?
Are there any examples for filtering or avoiding this bad intermittent value ?
0 Likes
9 Replies
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins
Dear Community Members,

Any thoughts on this topic ?
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Can you be more specific - what is the time base for the TIM? What values are you reading, for which frequencies? Can you show all the values reported up to and through the frequency switch?
0 Likes
lock attach
Attachments are accessible only for community members.
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins
Hello,

I have attached my Registers Configuration for the SCU and GTM modules. My PWM sensor is connected to MCU Port21 Pin#2. I have attached the port configuration for reference.
PWM & Duty from the sensor is not constant (~215Hz) , and for testing purpose I am publishing the value read from TIM registers on CAN.

As you can see in the data snapshot. There are few bad samples which are creeping into my readings. My goal is to find out what is causing these bad values and some sort of filtering mechanism from the TIM module (if possible).
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
I don't see any relevant errata for the GTM, and there are many applications doing this sort of thing without trouble.

P21.2 is a bit tricky though, because it can be an LVDS pad. Just to be sure, is P21_LPCR2=0?

Have you ruled out electrical noise? Do you have a scope with persistence that can spot anomalies over a long time period?

As an experiment, you might try enabling the pulldown on P21.2, or switching P21_PDR0.PL2 from 00 (automotive) to 2 (TTL 5V) or 3 (TTL 3.3V).
0 Likes
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins
Can you please clarify what is the significance of setting "P21_LPCR2 to 0 ?
In just observed that in my current configuration P21_LPCR2 is set to 0x00005480 [TX_PWDPD = Disabled, TX_PD = Yes, VOSEXT = 0, VOSDYN = 1, VDIFFADJ = 1, TX_EN = Disabled, TEN_CTRL = Port controlled,PS = 5V]
I will try changing to your recommended value and see what happens.

Have you ruled out electrical noise? - Yes the electrical noise is ruled out, we used Lecroy scope and did not observe any electrical noise

Also, below is my approach of reading the GPR1/GPR0 registers. Do you see anything wrong with this ?

/*Polling to check if NEW VAL flag is set */
if(MODULE_GTM.TIM[1].CH0.IRQ.NOTIFY.B.NEWVAL)
{
TimPwmPerid = MODULE_GTM.TIM[1].CH0.GPR1.U; //Read the latest captured measurement period value
TimPwmDuty = MODULE_GTM.TIM[1].CH0.GPR0.U; //Read the latest captured measurement effective level value

TimPwmPerid &= 0x00ffffff;
TimPwmDuty &= 0x00ffffff;

*Freq = (uint32)IPWM_INPUT_FREQ * 10 / TimPwmPerid;
*Duty = (uint32)((uint64)TimPwmDuty * 10000 / (uint64)TimPwmPerid);

MODULE_GTM.TIM[1].CH0.IRQ.NOTIFY.B.NEWVAL = 1;
}

I will try the pulldown on P21.2, and switching P21_PDR0.PL2 from 00 (automotive) to 2 (TTL 5V) or 3 (TTL 3.3V).

I am also seeing similar issue on all of the below PWM input pins

21.2, 21.3, 21.4, 21.5
22.0
22.1, 22.2, 22.3
23.0, 23.1, 23.2, 23.3
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
If it's happening on non-LVDS pins too, don't worry about P21_LPCR2.

NEWVAL doesn't stop GPR0 and GPR1 from being overwritten:

If the preceding PWM values were not consumed by a reader attached to the ARU (ARU_EN bit enabled) or by the CPU the TIM channel set GPROFL status bit in TIMi_CHx_IRQ_NOTIFY and depending on corresponding interrupt enable bit value raises a GPROFL_IRQ and overwrites the old values in GPR0 and GPR1. A new measurement is started afterwards.


Checking with a GTM expert, but can you try this in the meantime?


if(MODULE_GTM.TIM[1].CH0.IRQ.NOTIFY.B.NEWVAL)
{
MODULE_GTM.TIM[1].CH0.CTRL.B.TIM_EN=0;
TimPwmPerid = MODULE_GTM.TIM[1].CH0.GPR1.U; //Read the latest captured measurement period value
TimPwmDuty = MODULE_GTM.TIM[1].CH0.GPR0.U; //Read the latest captured measurement effective level value
MODULE_GTM.TIM[1].CH0.IRQ.NOTIFY.B.NEWVAL = 1;
MODULE_GTM.TIM[1].CH0.CTRL.B.TIM_EN=1;
...
}
0 Likes
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins
Hello UC_wrangler,

First of all, Thank you so much for helping me on this topic.

I tried the proposed solution and it didn't help. I understand that GPR0 and GPR1 will be overwritten in the continuous PWM measurement mode, however in my testing PWM from my sensor is constant (no change in freq or duty cycle) even if a new measurement occured since there is no change in freq/duty, GPR0 and GRP1 should not get corrupted with a bad value.

I think its something basic what I am missing here.

Can you help me get some example for TC377 device for TIM module ? It would be very helpful to just go through an example.
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Our GTM expert is pretty convinced it's noise. Can you try enabling filtering?

- Set TIMi_CHx_CTRL.FLT_CNT_FRQ to hopefully match your TIM timebase to keep things easy
- Set FLT_RE and FLT_FE (maybe try something fairly large like 25 first?)
- Set TIMi_CHx_CTRL.FLT_EN=1
- If you're seeing TIM_CH_IRQ_NOTIFY.GLITCHDET, that's a sure indicator of noise
0 Likes
nsyed
Level 5
Level 5
5 likes given 100 sign-ins 50 sign-ins
UC_wrangler wrote:
Our GTM expert is pretty convinced it's noise. Can you try enabling filtering?

- Set TIMi_CHx_CTRL.FLT_CNT_FRQ to hopefully match your TIM timebase to keep things easy
- Set FLT_RE and FLT_FE (maybe try something fairly large like 25 first?)
- Set TIMi_CHx_CTRL.FLT_EN=1
- If you're seeing TIM_CH_IRQ_NOTIFY.GLITCHDET, that's a sure indicator of noise


Thanks, I will enable the filtering and let you know
0 Likes