Skip to main content
Louie88
Senior
March 12, 2022
Solved

Frequency measurement with COMP1 and TIM2 NUCLEO-144 H723ZG board

I have NUCLEO-144 H723ZG board. 

I created a frequency meter app for the NUCLEO board, but the quality of the frequency measurement a sinusoidal voltage is very poor. I have a generated 720mV RMS, 126.7Hz signal between 0 and +2.5V (max) biased to +1.25V. On scope, the frequency meter connected to the output of the COMP1 shows 126.700x, the 4th digit is 1 or 0. The NUCLEO board measures almost 1Hz less than the frequency meter on scope (I checked it with a real frequency meter and the scope value is right).

My other problem is that the minimum value of the frequency = 125.451, the maximum value = 125.9264Hz, the average = 125.7246 and the standard deviation = 0.0775Hz. I could not measure the frequency as good as a simple scope.

Setup:

I enabled COM1 comparator. I connected the input sine voltage to the positive input (COMP1_INP) and I connected the negative input (COMP1_INN) to the +1.25V reference voltage to which the input signal is biased. With setting the COMP1 speed to “COMP_POWERMODE_HIGHSPEED�? I got terrible output voltage. Both edges of the output are bounced (200-250 spikes) at least 1-3us. Then I set the COMP1 speed to “COMP_POWERMODE_MEDIUMSPEED�? and I got only a couple of spikes. Then I set the COMP1 speed to “COMP_POWERMODE_ULTRALOWPOWER�? and I got no spikes. The hysteresis was always set to “COMP_HYSTERESIS_HIGH�?. Why? Can somebody explain it?

I connected the comparator output with a wire to the Capture Channel 1 input of the 32-bit TIM2. The timer runs on 275MHz (3.636ns) as a simple up counter, with ARR = 0xFFFFFFFF, Prescaler = 0. It is started with HAL_TIM_IC_Start_IT(&htim2, TIM_CHANNEL_1);

When rising edge of comparator detected on the Capture CHN1 input of TIM2 then TIM2 captures the value its 32-bit counter and calls the HAL_TIM_IC_CaptureCallback(). I read the capture 1 register and store the value in last period count if this is the first interrupt. It this is not the first interrupt then I subtract the current count from the last count (I also update the last value register to the current one). This is the period time in counts. I set a flag in the callback function to signal that I measured a new period time count. In the main() loop when this is true then I simply divide the 275MHz TIM2 clock with the period count. This is my measured frequency. Because I don’t have LCD and send it via serial port to the terminal APP of my notebook. The application runs continuously.

Even though this is a simple period time measurement I cannot not answer the following two questions.

  1. Why do I have so poor quality of the measurement? (See attached log picture)
  2. Why does the calculated frequency 1Hz less than the input signal frequency? This around 1Hz inaccuracy is constant. I can use any frequency it measures 1 Hz less. XTAL frequency problem? Or this is the side effect 2MHz * 275 with the PLL1?

Can somebody help. (Sample app for NUCLEO-144 H723ZG board is available if needed)

Thanks for any help, any idea.

Louis

This topic has been closed for replies.
Peter BENSCH
Peter BENSCHBest answer
ST Technical Moderator
March 18, 2022

Oops, sorry, Jan is right.

Yes, with ST-LINK-V3E you can set the MCO output to one of three possibilities:

  • Default (HSI/2) = 8MHz
  • HSE/3 = 25/3 MHz
  • Off

I have already crossed out my statement above.

I apologise for forgetting this for a moment.

Regards

/Peter

In order 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.

21 replies

Louie88
Louie88Author
Senior
March 18, 2022

Hi Peter,

Does it mean, if I select the HSE/3 check box in Help -> Upgrade ST-Link dialog box (and upgrade the firmware of ST-Link) then I will get 8.333 MHz crystal based clock? If so, then I have to modify the PLL settings because with the current settings it would generate 572.9166 MHz clock.

Thanks,

Louis

Peter BENSCH
ST Technical Moderator
March 18, 2022

Yes, correct.

In order 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.
Louie88
Louie88Author
Senior
March 18, 2022

Hi Peter,

It works! I have 1.00000kHz and the 5th digit is still stable.

0693W00000KdCdwQAF.bmp 

But the 25MHz/3 = 8.333333MHz cannot be set only to #define HSE_VALUE (8333333UL) (in the stm32h7xx_hal_conf.h file) so all the HAL_RCC_GetXXXClock() functions return a bit faulty frequencies. I do not understand why the 25MHz is divided by 3. Dividing by 4 would be better. This is 6.25MHz and 352 * 6,25MHz / 4 would still generate 550MHz. The #define HSE_VALUE (6250000UL) would be accurate and all the HAL_RCC_GetXXXClock() functions return right clock. Consider for the V4 version.

Thank you for your and jan's help. You saved the project.

Best regards,

Louis

Peter BENSCH
ST Technical Moderator
March 18, 2022
Great, excellent!
Maybe the software team will find another way to include the 25/4 and/or 25/5 option, let's wait and see.
Perhaps the 8.333MHz was choosen because that was closest to the MCO frequency of the older ST-LINK/V2 of 8MHz (HSI).
Regards
/Peter
In order 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.
Louie88
Louie88Author
Senior
March 18, 2022

Hi Peter,

Thank you very much and I appreciate your help.

Best regards,

Louis

waclawek.jan
Super User
March 19, 2022

> But the 25MHz/3 = 8.333333MHz cannot be set only to #define HSE_VALUE (8333333UL) (in the stm32h7xx_hal_conf.h file) so all the HAL_RCC_GetXXXClock() functions return a bit faulty frequencies.

Then don't use Cube/HAL functions to determine the frequency. Write your own: you know the *exact* rational (25/3) value, so why would you need to *call* any function to learn it?

I understand that Cube/HAL functions use this function internally. That's the basic problem with Cube/HAL: it caters only for a miniscule range of "usual" cases (any "library" inevitably is limited in this way). Anything slightly out of usual, and it gets into way more than it helps.

JW

Louie88
Louie88Author
Senior
March 19, 2022

Thanks Jan, I do not use any frequency related functions from HAL_RRC_***. This 8.333MHz is temporary solution. I ordered the 25MHz crystal and the two caps. We will use the 25MHz external crystal oscillator as HSE.

Thank you for your help.

Best regars,

Louis