cancel
Showing results for 
Search instead for 
Did you mean: 

HRTIM activates output immediately when re-enabled rather than on compare match

TechGuyMike
Associate III

I am using HRTIM in my project such that the output TA1 of timer A generates a delayed pulse after the timer is triggered via the EEV1 input. I have two compare values defined in Advanced configuration mode: One to set the output high and the other to set it low con compare match.

In my setup, the EEV1 is currently triggered every 100ms externally (I'm using a PWM output of another timer with a physical connection to the EEV1 input of my HRTIM timer).

One of the requirements of my project is the ability to shut down the outputs of the HRTIM timer at any time and also the ability to restart it.

As a test, put the following code in the main() function:

 

 

  while (1)
  {
    HAL_HRTIM_SimpleOnePulseStart(&hhrtim, HRTIM_TIMERINDEX_TIMER_A, HRTIM_OUTPUT_TA1);
    HAL_Delay(300);

    HAL_HRTIM_SimpleOnePulseStop(&hhrtim, HRTIM_TIMERINDEX_TIMER_A, HRTIM_OUTPUT_TA1);
    HAL_Delay(300);
  }

 

 

The expectation was that this code would repeatedly start and stop pulse generation on the TA1 output, but instead I'm getting the following picture:

TechGuyMike_0-1706749091117.png

Here's what happens:

1. Occasionally, my code in the loop shown above would call HAL_HRTIM_SimpleOnePulseStop() in the middle of the output pulse being active high, at which point one can see the last pulse in the sequence being cut short, which is expected:

TechGuyMike_1-1706749234563.png

2. Then a 300ms interval passes without any pulses on the TA1 output, which is expected.

3. Then, at the end of the 300ms "idle" period, the HAL_HRTIM_SimpleOnePulseStart() function causes the TA1 output to go high even though a compare match hasn't occurred:

TechGuyMike_2-1706749326418.png

This only happens when the previous pulse is cut short by the HAL_HRTIM_SimpleOnePulseStop() call.  I wasn't expecting this to happen. I though the output would only go high on compare match with compare unit 1 (basically, close to the rising edge of my EEV1 pulse on my screenshot above since my compare value is very close to 3).

My goal is to have the TA1 output only go high on an actual compare match and not when HAL_HRTIM_SimpleOnePulseStart() is called.  I know it's possible that HAL_HRTIM_SimpleOnePulseStart() isn't the right function to call, but I've tried using HAL_HRTIM_WaveformOutputStart() and it didn't work.  I've also tried resetting the timer counter to 0 and generating an update event before restarting the timer, and it didn't help. Does anyone have suggestions on how to resolve this?

1 ACCEPTED SOLUTION

Accepted Solutions

@Pierre_Paris Thanks for the response. I have to use HRTIM because all the other timer outputs are already taken in my setup and I need 2 timer inputs that can trigger a delayed pulse on multiple timer outputs each. HRTIM fits the bill perfectly (although the external event latency is the unfortunate downside).

So the issue I originally ran into was that instead of the output getting activated on the external trigger, it was occasionally activated on the periodic HAL_HRTIM_SimpleOnePulseStart() call. This was likely because the external event configuration was "External event is active on level" rather than "External event is active on Rising edge".

I fixed this issue by using the functions HAL_HRTIM_WaveformCounterStart() / HAL_HRTIM_WaveformOutputStart() to start the pulse generation and HAL_HRTIM_WaveformCounterStop() / HAL_HRTIM_WaveformOutputStop() to stop them.

I then ran into a similar issue when I needed to trigger the output pulse on the rising edge of the external trigger pulse.  This issue I had to solve by configuring the external event as "External event is active on Rising edge" in CubeMx.

So my setup is currently working as intended at this point. Thanks again!

View solution in original post

3 REPLIES 3
TechGuyMike
Associate III

The problem appears to be solved by calling HAL_HRTIM_WaveformCounterStart() just prior the loop and then calling HAL_HRTIM_WaveformOutputStart() / HAL_HRTIM_WaveformOutputStop() within the loop.

The only side effect is that the first pulse when the output is re-enabled might be shorter than the rest

TechGuyMike_0-1706751075843.png

 

Pierre_Paris
ST Employee

Hello @TechGuyMike,

I didn't really get your application, here some questions :

  • What is your application ? Can you give more details and your configuration ?
  • Why are you using the HRTIM and not a simple timer in one-pulse mode with the HAL API HAL_TIM_OnePulse_Init() for example? The accuracy should be all right.

I advise you to read chapter 39.3.13 of RM0433. You can set a time delay and a time pulse. 

Kind Regards,

Pierre

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

@Pierre_Paris Thanks for the response. I have to use HRTIM because all the other timer outputs are already taken in my setup and I need 2 timer inputs that can trigger a delayed pulse on multiple timer outputs each. HRTIM fits the bill perfectly (although the external event latency is the unfortunate downside).

So the issue I originally ran into was that instead of the output getting activated on the external trigger, it was occasionally activated on the periodic HAL_HRTIM_SimpleOnePulseStart() call. This was likely because the external event configuration was "External event is active on level" rather than "External event is active on Rising edge".

I fixed this issue by using the functions HAL_HRTIM_WaveformCounterStart() / HAL_HRTIM_WaveformOutputStart() to start the pulse generation and HAL_HRTIM_WaveformCounterStop() / HAL_HRTIM_WaveformOutputStop() to stop them.

I then ran into a similar issue when I needed to trigger the output pulse on the rising edge of the external trigger pulse.  This issue I had to solve by configuring the external event as "External event is active on Rising edge" in CubeMx.

So my setup is currently working as intended at this point. Thanks again!