VREF as comparator input fails but equivalent DAC input works just fine. Why?

KHarb.1 · ‎2024-05-06

I have a signal biased around the VREF output (2.048V) of an STM32G4. I have a comparator (COMP7) peripheral configured to compare this signal to VREF and it fails. If I set the second input of the comparator to DAC2 and set the DAC2 output value to max (0xFFF), the comparison works. Both should have the same behavior, but using the VREF comparison directly doesn't work. What could I be doing wrong?

Michal Dudka · ‎2024-05-22

Take a look on figure 168 in reference manual:
https://www.st.com/resource/en/reference_manual/rm0440-stm32g4-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
There you can see that comparator negative input can be GPIO, DAC and Vrefint (!) and its fractions (buffered by "scaler"). This Vrefint have nothing to do with VREF used as DAC reference. If you use DAC referenced by 2.048V from VREF (called VREFBUF) with data 0xFFF, then comparator see on its negative input about 2.048V. And it is close to your measure signal. But when you connect comparator input to "Vrefint", then comparator see about 1.2V threshold and it is far from your signal level.

There is no way how to connect comparator to VREF (2.048V) directly. Only way is through DAC. Therefore your claim:

@KHarb.1 wrote:
I have a comparator (COMP7) peripheral configured to compare this signal to VREF...

must be wrong. You are probably confused by two different voltage references..

View solution in original post

AScha.3 · ‎2024-05-06

How you set the comp input selector ?

If you feel a post has answered your question, please click "Accept as Solution".

KHarb.1 · ‎2024-05-07

I used CubeIDE to change the settings.

I'm using the externally exposed VREF, so I know it's working that way. Are there extra init commands for using an internal VREF with a comparator?

AScha.3 · ‎2024-05-07

>I used CubeIDE to change the settings.

ok.

>Are there extra init commands

No.. Did you try to select other comp inputs , like vref/2 ?

If you feel a post has answered your question, please click "Accept as Solution".

KHarb.1 · ‎2024-05-07

No. The input signal is biased around VREF, so using VREF/2 would always yield a stuck value.

AScha.3 · ‎2024-05-07

Ok, so - did you look at errata of your cpu type ? (Just to be sure, there is no known problem.)

+

If select external pin input, connect this to vref then, working ?

If you feel a post has answered your question, please click "Accept as Solution".

KHarb.1 · ‎2024-05-07

Nothing in errata.

I can't use an external pin for testing on this board. I'm outputting VREF just fine though.

AScha.3 · ‎2024-05-07

So no simple test to prove -

- i would take the DAC as ref input, as its working, as you want. At least a good workaround .

- if there is a problem with the chip, you should ask STM about, to clear this : http://my.st.com/ols

If you feel a post has answered your question, please click "Accept as Solution".

KHarb.1 · ‎2024-05-21

The above solution of using DAC2 worked for COMP6 and COMP7.

I've moved on to needing to use COMP2 and COMP4. These ones also don't work as expected. I have to set the DAC value to about half of the maximum value to get very unstable behavior. I verified that the input signal is biased at what the maximum DAC value should be, so setting the DAC to max as before should work like it did before but it doesn't.

AScha.3 · ‎2024-05-22

All this is on a custom board - right ?

So you have something like a NUCLEO-G431RB, NUCLEO-G474RE, or NUCLEO-G491RE , to test on this board and see : hardware related problem or software or a chip problem ?

>These ones also don't work as expected

-> on your board ! Need a reference , to come closer to the problem, so take a nucleo and compare .

+

I hope, you have nothing else running on the analog , like ADC , ... ?

+

You need to put a cer.cap (10n or 100nF) close to comp in -- gnd plane. Do you ?

If you feel a post has answered your question, please click "Accept as Solution".