Drive COMP RESULT on GPIO

[StefXinet]

I am developing a product with nRF52832 in which we need to use the COMP module. We need to route the RESULT signal directly to the RX input of the UART, or to an output of the GPIO.
From the datasheet this does not seem to be possible: the only way to read the COMP result is through bit 0 of the RESULT register.
How can we go about using the COMP?
thank you.

[ovrebekk]

Hi 

Could you not use the DOWN and UP events of the COMP peripheral to control your pin, rather than the RESULT register?

EVENTS_DOWN is triggered when the input goes below the reference. and EVENTS_UP occurs when it goes above the reference. 

Using a GPIOTE OUT channel and the PPI controller you can connect these two events so that they are reflected on a pin. 

Best regards
Torbjørn

[Julian Schindler]

Hi,

In my application the comparator (single ended mode, NRF52833) is used as a constant-current-sink buck driver

• VIN+ is connected to a shunt resistor (0.14V @700mA load current)
• VIN- uses refernce ladder on internal voltage reference ( Vdown=0.13V, Vup=0.15V)
• output pin controls highside switch (PFET)

I used the Event / Task solution with two different settings:

1.
EEP: NRF_COMP_EVENT_UP -- TEP: NRFX_GPIOTE_TASK: CLR
EEP: NRF_COMP_EVENT_DOWN -- TEP: NRFX_GPIOTE_TASK: SET

2.
EEP: NRF_COMP_EVENT_UP -- TEP: NRFX_GPIOTE_TASK: CLR
EEP: NRF_COMP_EVENT_DOWN -- TEP: NRFX_GPIOTE_TASK: OUT (Polarity: LoToHi)

For this application a high switching frequency is required (>100kHz) as well as a small hysteresis. The setup works fine most of the time but i got the following issue:

With both settings, it could happen that the output pin reflects not the OUTPUT state of the comparator. This is when UP and DOWN events are triggered simultaneously (during the same clock cycle).

According to the task prioritys (OUT > CLR > SET), it results in: (i measured both cases)

1. Output pin could stuck in low state, while comparator OUTPUT = high
2. Output pin could stuck in high state, while comparator OUTPUT = low

Any suggestion of how to make sure, that the output pin is set according to the correct comparator event? Where the "correct" event is the recent one (not the one with the higher priority).

Thanks,

Julian

[ovrebekk]

Hi Julian

I will check with the hardware designers if they know of a good workaround to this situation. 

Have you tried to add some kind of RC filter to the input signal, in order to remove the high frequency component of the signal?
Possibly this is the best way to handle the situation, unless we can identify some kind of internal workaround. 

Best regards
Torbjørn