TMS570LS3137: ICU driver behavior is improper for low frequency input signals

Hello,

Is the measured dutycycle and frequency incorrect occasionally or all the time? How big is the difference?

Hi,

The measured frequency and duty cycle are incorrect all the time. The output value from Icu_GetDutycycle() is oscillating between 0 and the actual values that are fed from the signal generator all the time.

Hello,

The measuring of dutycycle and period uses the N2HET PCNT instruction. For FALL2FALL and RISE2RISE, the user should always discard the first interrupt if interrupt is enabled before HET_ON. For both the types, reset edge and capture edge are the same and the interrupt is triggered on capture edge.

Once the execution unit is enabled, the first edge generates an interrupt but the value of the counter is of no use as this is not the period between 2 edges. So first edge after turning on N2HET is used mainly for resetting the counter and start the period count.

The counter is 25 bits long (PCNT control field C24:C0), and is reset by the the edge. I don't think that this counter can be overflow.

Hello,

Since we are integrating and using the TI delivered AUTOSAR MCAL package, I believe all these interrupt processing are happening in the MCAL driver layer. As an application developer, we are only configuring the ICU NHET pins.

I am developing application code in which I need to read the input frequency and duty cycle.So,  I am calling the API Icu_GetDutyCycleValues() to get the period and active time every 10ms. The results from this API are not correct and toggling between 0 and the actual value when the input frequency is less than 100Hz.

Please let us know if this is the limitation from ICU driver in the MCAL package.

The following are the limitation if ICU/PWM driver:

Limitations:

1. The smallest time unit possible to be measured is 2LRP(256 ticks)
2. Any actions (such as API calls) will take at least 1LRP (ie.128) to execute.
3. There can only be 15 ICU channels per N2HET(i.e. 30 channels totally) (Note:- The 15th channel shall not be a signal measurement channel for duty cycle)
4. Wakeup configured channels will wake up the module only if the MCU is in Normal mode. This is because the NHET clock is turned off when MCU goes to sleep mode. So ICU module cannot be used to wake up the MCU.

Please refer to the user guide under ICU folder of MCAL driver.

Hello QJ,

ICU inputs are not measured correctly if the input frequency is less than 100 Hz.

Configured VCLK2 value is 80 Mhz.

For Eg,

50 Hz =  12500 ticks, which is far greater than 256 ticks. But, ICU period and duty cycle are toggling between 0 and actual values. 

I could not relate this behavior to any of the ICU driver limitations mentioned above. Please explain.

Hello,

Can you shared Icu_PBcfg.c and the ISR in which the ICU APIs is called ( for example Icu_GetDutyCycleValues(1, &DutyCycle))? 

Hi,

Please find the file attached.

ICU API is called in a 10ms periodic task.4621.Icu_PBcfg.c

Hello,

Configuration is good. When you calling the APIs, did you add some delay between two API calls? Since the input signal is very slow (100Hz), and you need to leave some time for NHET to capture the rising/falling edges of the input signal. For example, delay of at least 10ms is needed for 100Hz input signal.

Icu_StartSignalMeasurement(channel);

delay(..)  ---- shoulbe be > 10ms in polling mode

Icu_StopSignalMeasurement(channel);

Hi,

I tested with different delay values (10ms, 100ms and 1000ms) but no improvement in the behavior.

Still, ICU inputs are toggling between 0 and the actual input. Please provide an alternate solution.

Hi,

I'd like to test it, but I don't have a already working CCS project. Can you share your code with me for testing? 

Hi,

Sorry, I am working on a project where the customer policy do not allow me to share the project contents.

Could you please test with your test code and confirm if it is hardware or software issue?

Hi QJ,

I did a quick test with Halcogen generated PWM driver. I am able to read lower frequency PWM inputs (30Hz) in the SW with halcogen driver without no toggling.

The issue is evident only in Autosar MCAL driver. Could you please check and inform any other solution to overcome this.

Sorry, there is a typo error in above comment.

I am able to read lower frequency PWM inputs (30Hz) in the SW with halcogen driver without any toggling/oscillation.

Hi QJ,

I hope you are getting the values without oscillation.

I am running the same code in the function that runs every 10ms and seeing lot of oscillations.

Have you checked with calling ICU API with delays?

Hello,

There is no oscillation when I read the period and duty. The value is persistent.

Is your input a valid PWM signal with a unchanged period and duty?