COMP (or PPI) drops event

[snoopy20]

Hi,

I previously wrote about an unexpected behaviour which I've made a diagram for below. It's relatively simple though, the COMP watches a voltage and fires a toggle event through PPI which is received by GPIOTE which toggles it's pin which controls an external circuit responsible for the voltage that COMP watches.

First the external circuit is switched off by a secondary means and the system is synced, so GPIOTE goes high and COMP goes high, then the secondary means is turned off so the driver activates and then it's purely a hardware based implementation.

I previously replicated the behaviour when the COMP speed was set to normal. This suggested that PPI or GPIOTE couldn't keep up with the events it was generating OR COMP was/is sometimes failing to generate the toggle event when the voltage has recovered. The behaviour means the GPIOTE remains low when the voltage has recovered.

The COMP speed was set to low, so 1MHz, and on the bench this appeared to have resolved the issue. However, a user is now reporting it again.

[Susheel Nuguru]

The main issue here seems to be that your loop here seems very fragile where it depends on toggling instead of relying on a deterministic state.

My suggestion is that you can map

COMP->EVENT_UP → GPIOTE TASKS_SET
COMP->EVENT_DOWN → GPIOTE TASKS_CLR

So that we are sure that the ping goes high if the voltage goes above threshold and vice versa.

[snoopy20]

I don't see why it's fragile, only the COMP generates the signal and only COMP has control over the 'thing' that affects the signal. It's closer to a true hardware UVLO implementation this way.

Originally many moons ago I had implemented it by the method you describe but found it didn't work, probably because the comp was generating the events too close together and they were racing to be processed. This may however have been with the COMP on normal or fast speed and may be worth a revisit, but I have my doubts whether it will fix the underlying issue.

I should elaborate further. The external circuit is a slow turn-on (ramps) but a fast off. This will mean when the COMP generates its below signal triggering gpiote the above signal is going to follow quickly. Indeed it is this above signal which is 'missing' on occasion. 

I know that setting the COMP to slow almost fixes the issue.

[snoopy20]

Sure, there's no rush, the 'solution' is working and everyone is happy.

[Hieu]

Hi snoopy20,

I am updating regarding one of the questions:

snoopy20 said:

2. The upper hysteresis resistor is set to trigger at 4.8v (nominal voltage is 5v +/- 1%). The tolerance of the comp hysteresis is unknown, does it change with temperature, does the comp speed change the tolerance (it does on PIC16 as an example)?

Both can contribute the tolerance of COMP. Temperature makes the reference voltage drift, and higher operation speed could potentially have an impact on internal offset of COMP, limiting accuracy of the circuit.

The other questions will have to wait even longer unless they become critical for the design. Our apologies for the inconvenience.

[snoopy20]

No problem, the current solution is working in all temperatures so it is known to not be the problem. It is known that GPIOTE can't keep up with the 1MHz speed of PPI.

It's easy to wire something up on NRF52DK by connecting a digital pin to a capacitor with pull-up enabled in parallel with an analog pin for the comp and validating the issue. I figure the newer chips are using the same GPIOTE so worth the investigation?

[Hieu]

snoopy20 said:

I figure the newer chips are using the same GPIOTE so worth the investigation?

I really don't know, and even if I do, I doubt I have the liberty to comment about it on DevZone. But I will trust our engineers' judgement on this.

[snoopy20]

It needs addressing, if the peripherals can't perform to specification it can be a show-stopping decision. These days miniaturising hardware on-board is too important. I feel very, very lucky that I found a solution here as the application can be safety critical and I'd be in a really bad place on refunds otherwise.