STM32G431 Comparator BUG

[Michal Dudka]

Hi,

Few days ago i've encountered a strange behavior of the comparator at STM32G4. I investigated the problem under controlled conditions (used Nuclo kit instead application PCB) and the result is startling.

Comparator 4 configured to get positive input from pin PB0, negative from DAC1 Channel 1 (set to 500mV).
Hysteresis set to maximum (70mV)
DAC output is not connected to external pin (only internal connection)
Input signal is 50Hz sinewave with 400mV amplitude and 600mV offset (to reliably cross 500mV thresholds +- hysteresis)
Enabled Comparator 4 rising edge interrupt.
Interrupt routine simply generates fixed length pulse.

On blue scope trace you can see clean input signal (scope input AC coupled), it certainly does not contain noise that would be close to hysteresis value (more detail at last screen).
On Red trace is application output. You can see that many times interrupt fires also on falling edge, or fires multiple times on tha same rising edge. It looks like that comparator works withou hysteresis. But if you take a look on next screenshot, you will se comparator HW output (yellow) witch marked thresholds. They are separated by about 40mV which corresponds to "typical" value of "70mV" hysteresis. And of course, comparator registers are correctly set to hysteresis level "7".
On yellow trace is comparator HW output (PB6)
Last screenshot shows that there is not excesive noise to "false" trigger comparator.

False falling edge detectionDouble rising edge detectionHysteresis provedSmall noise

I am using STM32G431K Nucleo board, MCU clocked 170MHz from internal oscillator, powered from USB.
Source code included.

[Michal Dudka]

It seems that a comparator with 70mV hysteresis which is flipped by less than 10mV noise is not an interesting topic. To be sure that i am not wrong, i've measured comparator HW output by 1GHz active probe (included screenshots).

I will summarize the observation:
1. EXTI often catch rising edge on comparator output even input signal is falling
2. Input signal noise (<10mV) is much less then comparator hysteresis (nominal ~70mV)
3. That happen even if any fast or sensitive signal is outputed from MCU (comparator HW output disabled, DAC output only internal)
4. Regardles of MCU clock frequency (16MHz or 170MHz)
5. Nasty spikes can be seen on comparator HW output if enabled (and pin speed set to maximum) - I susspect these spikes are inside MCU and are source of problem (EXTI is fast enought to detect them).

Anybody who will want to detect "reasonable low" noise slow rising or falling edge by comparator on STM32G431 will have to find some workaround.

[waclawek.jan]

> It seems that a comparator with 70mV hysteresis which is flipped by less than 10mV noise is not an interesting topic

It is an interesting, but at the same time also hard, topic.

As you've demonstrated, the hysteresis as such works, so that's not the primary issue here (and, as you've noted, the digital clocks are not that relevant here, as EXTI is asynchronous and apparently perfectly capable of capturing the spikes you're observing).

I'd say, this is entirely unrelated to the input signal's noise either. If anything, the input signal's impedance may be questioned, but then, the blue traces in initial post are measured directly at the comparator input pin, aren't they? 

So, I'd say the output capacitively coupling into the other (reference, DAC-driven) input, or a more complicated effect within the comparator itself e.g. through common ground impedances or through VREF+->DAC.

So, I'd start with looking closely at the DAC output and at VREF+ (and perhaps even at VDDA?). I'd try to bring out DAC to external pin and decouple, and/or try some stable external voltage used for negative comparator input instead of the DAC.

In the past, @Igor Cesko was providing here excellent help with the 'G4 ADC; maybe he can offer some insight into other analog features of 'G4 such as DAC and COMP, too?

JW

PS. You don't use the S&H mode of DAC, right?

[Michal Dudka]

I am not using S&H mode and blue traces are measured at input pin. Thanks to pointing on VREF+. STM32G431 have VREF+ hardconnected to VDDA. I checked the VDDA supply voltage and it is clean (SB5 jumper on G431KB nucleo removed). I also tried bring DAC output to GPIO and add filter (22nF to GND) and with no effect. DAC output voltage is clean too. I've didnt tested ground bounce, but i suppose that ground impedance on Nucleo32 kit is low enought. And moreover i've measured the same behaviour on two different PCBs with exactly the same "glitch shape".

To summarize:
6. Enabling, disabling compartor output neither its slew rate have no effect - no fast signals outside MCU
7. AVDD looks clean (scope trigger synchronized by comparator slew limited output), DAC output (if used) looks clean the same way (trace included).
8. Changing comparator negative input from DAC driven to "internal Vref" driven have no effect. Exactly the same output glitch shapes.
9. Lowering input waveform slew rate to stay at threshold voltage for a longer period of time have no effect. Duration, rate and shape of spikes are the same.

Used comparator 4 have no external connection for negative input. To test fully externaly controlled comparator i have to change test setup. That may or may not bring another information about cause of problem. But probably does not change anything on original problem with comparator with internal DAC/Vref threshold.

It looks like that threshold change (hysteresis) is slower then comparator and therefore there is short "window" where comparator works effectively without hysteresis.

by the way, what is purpose of SB5 ?

[waclawek.jan]

Sorry, I have nothing relevant to add.

> by the way, what is purpose of SB5 ?

This?

No idea...

JW

 

[KHarb.1]

Seems close to stuff I'm seeing:

https://community.st.com/t5/stm32-mcus-products/vref-as-comparator-input-fails-but-equivalent-dac-input-works/td-p/670815

 

[Michal Dudka]

I dont think it is close. But it looks like that you are confusing VREF and Vrefint in your original question (i will reply in original thread).

[waclawek.jan]

And could this be related - i.e. do you have any other analog peripheral active?

JW

[Michal Dudka]

As far as i know it is not related. He was performing ADC measurments on the same channel where was comparator input connected and ADC sampling simply changed input voltage, probably due high signal impedance.

I believe it is silicon bug, arising from super fast comparators, probably fastest i've ever seen on MCU. I've casually tested them and they can handle much shorter pulses then 17ns (propagation delay) and i will test them properly soon, when my student begin to work on pulse detector.

[waclawek.jan]

Sorry I haven't noticed that the ADC works on the same pin.

However, my point was, couldn't other analog functionality impact output of DMA or the comparator itself, via common supply/reference/ground paths or otherwise. There are several non-digital ADC errata (End of 10/8/6-bit ADC conversion disturbing other ADCs, ADC input channel switching disturbs ongoing conversions, An ADC instance may impact the accuracy of another ADC instance at specific conditions), and also the 'G4-specific ADC appnote, indicating, that while 'G4 is aimed at replacing 'F3 as the mixed-signal solution, there may be shortcomings in the analog paths.

Also, IIRC, ST mentioned reduced number of GND/VCC pins on the 'G4 (and 'G0) citing some innovative power arrangement; I am lazy to look this up at the moment, but that also might rise doubts.

That's why I was asking, whether you are running some other analog functionality alongside the COMP test.

JW

 

PS.

>I believe it is silicon bug

Maybe. However, I am somewhat reluctant to accept the idea ST would not perform basic COMP testing on what again is supposed to be a mixed-signal family. I can imagine a scenario where they tested it in separation, see above. I also can imagine that certain packages perform worse than others and the chip was tested in some particular package or as a bare chip. I can also imagine

Nonetheless, at this point, given your findings, pending further explanation from ST, I personally would not consider the 'G4 COMP as usable. I would perhaps consider external comparator instead, or would perhaps also consider the "more conservative" 'F3 (although, differences in COMP details between the 'F303xB/xC and 'F303xD/xE may rise questions too).

[Michal Dudka]

I am runing only DAC to set comparator threshold. Any other analog peripherals is not enabled. Chip run at minimal configuration to demonstrate problem, just DAC,Comp,GPIO,EXTI.

I agree that it is necessary to be conservative when declaring it as silicon bug - lets call that "a disturbing observation". It is up to ST whether they will somehow verify these findings. I probably won't do any more tests. I spent some time on it just because I found it interesting and it can probably save some debug time to somebody else. It does not complicate my work in any way (I do not deploy STM32 in large series) and workaround was simple in my case.

[AScha.3]

>it is necessary to be conservative when declaring it as silicon bug

Right. I see nothing "wrong" here , just look (with your "false trigger problem") at a scope, DSO or analog,

set trigger close to zero/center , on rising , and input just mains (50 or 60Hz) (simply by touching the 10:1 probe tip, getting the stray-in-hum :( 

most scopes will show a mix of "right" and "wrong" traces,  most triggered at rising zero cross, some at falling.

Why ?

Well , when signal rising and trigger set to rising - its doing what we expect.

But at falling signal, when at zero crossing, any tiny EMI/spike giving a small falling+rising signal, maybe only for some nanoseconds , but for a hi-speed circuit enough, to say: ok, rising signal at zero cross -> trigger now.

And we have cell phone, WiFi nets etc always around, so some mV spikes you will see on every unshielded wire , longer than 20mm . 

So if want test something like this, to prove, its a chip bug : first go in a 100% RF tight environment and build also the test setup in a magnetic shielded box - then you might see, is there a EMI/spike source , coming from the chip - or not.

And using the hysteresis improving the "false" trigger, shows: this is the problem.

So with 10mV noise and whising a 100% correct trigger, i guess you need minimum 500mV hysteresis, to be on the "save side" .

And just to think about: we see here a "problem" , that might come from some mV spikes on the input - but where is this sensible circuit sitting ? Some micrometers away from busy switching thousands of gates at 1..3 V levels with swichting times < 1 ns . So -for me- more surprising, it can work at all with such "neighborhood".

[waclawek.jan]

> I am runing only DAC to set comparator threshold. Any other analog peripherals is not enabled.

So this question is settled, then. Thanks.

JW

[KHarb.1]

Is this only with COMP4?  I just started using an STM32G473 and after some confusion, I see COMP7 and COMP6 working normally...but COMP4 with DAC3 as reference does crazy things.

[Michal Dudka]

I have not tried it on other comparators or on another chip. In some project i've used all 7 comparators on STM32G474 each driven by separated internal DAC channel and they works perfectly (on signals with fast edges, about slow i can't say anything).

[STOne-32]

Dear @AScha.3 @Michal Dudka @KHarb.1  @waclawek.jan ,

Thank you for reaching us on this behavior of the comparator and Hysteresis of STM32G4, we will check to reproduce and back to you in next days.   Much appreciated !

Ciao

STOne-32.

[Simon V.]

Hello Michal,

What you are observing may be relative to the Miller effect inside the comparator circuitry.

Would it be possible for you to set bit#1 (not documented) in COMP_CxCSR, it enables a compare feature which hold the comparator output during the duration of the Miller effect.

On my side, using your setup and a nucleo board, I was able to hold the comparator output during the falling phase and obtain the expected behavior. 

Regards,

Simon

[Michal Dudka]

---

@Simon V. wrote:

Would it be possible for you to set bit#1 (not documented) in COMP_CxCSR, it enables a compare feature which hold the comparator output during the duration of the Miller effect.

---

Thanks Simon,
It works, artefact dissapears, and comparator works as expected. May be you should mention that in user manual.

BTW: Did you tested Nucleo32 (STM32G431KB) or bigger Nucleo64 (STM32G431RB) ? I've observed this effect on two different PCBs (Nucleo32 and my PCB), both with STM32G431KB.