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.

[snoopy20]

Hi Hieu,

It's not of great urgency. Currently I can't replicate it on the bench (switching to 1MHz fixed it for me). I have two production users that are trying to replicate, when it does they can capture evidence in the accompanying App.

The output is a TLV62090. The input is analog, there is no jitter. So long as PPI/GPIOTE are faster then COMP then COMP monitors and controls the circuit.

I use the NRF52's pull-up and high disconnect config as a secondary override so COMP state and GPIOTE state remain in sync, and the TLV62090 has a soft-start. The turn-on will therefore be much slower then the turn-off. When the COMP turns the TLV62090 off the voltage will recover fast and of course this appears to be what it has trouble capturing.

I can only see that it is capturing the recovery too close to the turn-off point, that is to say COMP is overwhelming PPI or GPIOTE. There is no other logical explanation.

The only other reason would be the upper hysteresis point of the COMP becomes invalid, so as the voltage rises it no longer strikes a match. I don't do anything special here, the value is set on boot and reasonably below the recovery voltage to ensure it strikes with a good margin (4.8v vs 5.0, 1% resistor divider then whatever the % deviance of the internal res/hys is of the COMP). Unless there's a lot of variance around temperature - my users will be in different outdoor environments likely ranging from 0-30c at the moment. The CPU temperature will be captured in the App as well.

[snoopy20]

I have confirmation and evidence from a user showing it's real.

I'm about to replicate his exact settings at this end but so far I've been unable to reproduce, the COMP is firing correctly here. My unit is at 23c and his is at 9c CPU temperature, I'll freeze mine later and see if there's a change.

[snoopy20]

Alrighty, so I can now replicate it on the bench. It takes a lot longer but usually 5-10 minutes of UVLO activity will eventually cause it.

So far it occurs with the CPU at 9 or 25c, so discounting temperature.

When it occurred I was watching the state of the system in the App and no event fired which would/might/possibly - have done anything that I can possibly thing would be related.

I tried applying https://docs.nordicsemi.com/bundle/errata_nRF52810_Rev3/page/ERR/nRF52810/Rev3/latest/anomaly_810_155.html but with no luck.

The COMP sample output also goes to the App so I can see it is reporting power is above the reference.

Finally I snuck a little hidden feature in so I can manually fire the GPIOTE TASK_SET which confirms it hasn't crashed internally (if that's even possible) and also confirms the external driver is working correctly.

I have to conclude this is a hardware issue being:

1. sometimes the COMP doesn't generate an event for an EVENT_UP (or cross) or
2. PPI is overwhelmed by the speed of COMP in low/slow mode (1MHz) or
3. GPIOTE is overwhelmed by the speed of COMP in low/slow mode (1MHz)

[snoopy20]

And finally for tonight another observation.

I decided to go back and retry the SET/CLR method, but I only implemented for one of the three external drivers (all of which do the same thing).

The SET/CLR method failed first, so is worse.

It pretty much validates my hypothesis, PPI or GPIOTE can't keep up with the speed of COMP in it's lowest speed. This is quite troubling as I have no mitigation for it.

[snoopy20]

I kept at it and may have a solution, it appears to be working so far.

I don't have any timers left but have an RTC ticking at 8KHz.

I wire the COMP UP event to enable a PPI group. Two PPI's linked to the RTC tick fire the GPIO SET and disable the PPI group.

Questions are:

1. If the COMP UP event and the RTC tick event come in at the same time will the enabling of the group also fire the PPI on the same clock? It seems unlikely, but possible.

2. If the COMP UP event comes in and the RTC tick is one peripheral clock later, then the added delay is just 1/16MHz. This is still much faster then the 1MHz of the COMP, which is known to be fast enough to create the original issue.

So far though it appears to be a solution. As long as enabling the PPI grp and the PPI event it controls firing at the same time won't actually trigger the PPI (aka 1) then I will wire in a second GRP also working on the RTC tick, which will avoid (2). Thus, the outputs will be SET on the second RTC tick.