COMP (or PPI) drops event

RE: COMP (or PPI) drops event

snoopy20 — Tue, 03 Jun 2025 13:14:01 GMT

It's too late for that, however I'm not moaning as the solution works.

RE: COMP (or PPI) drops event

Hieu — Mon, 02 Jun 2025 12:33:20 GMT

I fully agree that any limitations should be identified and described in the product specifications. However, as a support engineer on DevZone, I can't do anything further on pushing this investigation.

If the issue was a risk to your project, could you please have a word with your Nordic sales contact? They will want to know it and might be able to help.

RE: COMP (or PPI) drops event

snoopy20 — Thu, 29 May 2025 09:47:50 GMT

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.

RE: COMP (or PPI) drops event

Hieu — Tue, 27 May 2025 13:08:00 GMT

[quote user="snoopy20"]I figure the newer chips are using the same GPIOTE so worth the investigation?[/quote]

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.

RE: COMP (or PPI) drops event

snoopy20 — Tue, 27 May 2025 12:55:40 GMT

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?

RE: COMP (or PPI) drops event

Hieu — Tue, 27 May 2025 10:50:18 GMT

Hi snoopy20,

I am updating regarding one of the questions:

[quote user="snoopy20"]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)?[/quote]

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.

RE: COMP (or PPI) drops event

snoopy20 — Tue, 22 Apr 2025 18:55:00 GMT

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

RE: COMP (or PPI) drops event

Hieu — Tue, 15 Apr 2025 21:55:44 GMT

I am afraid I am unqualified to comment on this solution 😅. I see what you are doing, but I lack the knowledge to evaluate it.

But it's great to know that you have a working solution now.

I will follow-up regarding the unanswered questions once I receive a response for my internal query. However, it looks like that has to be after the Easter holiday. My apology for the inconvenience.

RE: COMP (or PPI) drops event

snoopy20 — Tue, 15 Apr 2025 07:06:56 GMT

The frequency of the loop is dictated by the speed of the COMP, which in low power mode is 1MHz according to the datasheet.

Your understanding of the system is correct. Then your third points are:

1. correct, if the sink is too much VDD will drop
2. the speed of the missing event (Vdd recovered) is dependent on how fast TLV62090 turns off and then how fast COMP toggles its state. The turn off by TLV62090 will be very fast, microseconds at worst. The state (Vdd recovered) is then waiting for COMP to detect it.
3. there's really not much to it. COMP detects Vdd, state goes to PPI/GPIOTE and toggles thing which affects Vdd, so equilibrium.

The PPI GRP workaround is a success (the RTC is just to clock, could use anything). I've ran it for hours.

The solutions slows down the EVENT_UP propagation and so clearly tells me the problem is not with COMP or PPI because it's now working, so the problem is with GPIOTE. It isn't fast enough to handle 1MHz PPI events.

  // GPIOTE turn-offs
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR].EEP = (uint32_t) &NRF_COMP->EVENTS_DOWN;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR].TEP = (uint32_t) &NRF_GPIOTE->TASKS_CLR[CFG_GPIOTE_POWERMANAGER_FRONT];
  NRF_PPI->FORK[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR].TEP = (uint32_t) &NRF_GPIOTE->TASKS_CLR[CFG_GPIOTE_POWERMANAGER_REAR];

  // -- enables first group, awaits a tick
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_GROUP].EEP = (uint32_t) &NRF_COMP->EVENTS_UP;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_GROUP].TEP = (uint32_t) &NRF_PPI->TASKS_CHG[CFG_PPI_GROUP_POWERMANAGER_ENABLE_NEXT].EN;

  // -- enables next group on tick, disables self (one shot)
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_TIMER_GROUP_NEXT].EEP = (uint32_t) &CFG_SCHEDULER_TIMER->EVENTS_TICK;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_TIMER_GROUP_NEXT].TEP = (uint32_t) &NRF_PPI->TASKS_CHG[CFG_PPI_GROUP_POWERMANAGER_ENABLE_NEXT].DIS;
  NRF_PPI->FORK[CFG_PPI_POWERMANAGER_TIMER_GROUP_NEXT].TEP = (uint32_t) &NRF_PPI->TASKS_CHG[CFG_PPI_GROUP_POWERMANAGER_ENABLE_SET].EN;
  NRF_PPI->CHG[CFG_PPI_GROUP_POWERMANAGER_ENABLE_NEXT] = 1 << CFG_PPI_POWERMANAGER_TIMER_GROUP_NEXT;

  // -- sets outputs, disables self (one shot)
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_TIMER_FRONTREAR].EEP = (uint32_t) &CFG_SCHEDULER_TIMER->EVENTS_TICK;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_TIMER_FRONTREAR].TEP = (uint32_t) &NRF_GPIOTE->TASKS_SET[CFG_GPIOTE_POWERMANAGER_FRONT];
  NRF_PPI->FORK[CFG_PPI_POWERMANAGER_TIMER_FRONTREAR].TEP = (uint32_t) &NRF_GPIOTE->TASKS_SET[CFG_GPIOTE_POWERMANAGER_REAR];
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_TIMER_GROUP_SET].EEP = (uint32_t) &CFG_SCHEDULER_TIMER->EVENTS_TICK;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_TIMER_GROUP_SET].TEP = (uint32_t) &NRF_PPI->TASKS_CHG[CFG_PPI_GROUP_POWERMANAGER_ENABLE_SET].DIS;
  NRF_PPI->CHG[CFG_PPI_GROUP_POWERMANAGER_ENABLE_SET] = 1 << CFG_PPI_POWERMANAGER_TIMER_FRONTREAR | 1 << CFG_PPI_POWERMANAGER_TIMER_GROUP_SET;

I hope you like the solution, I'm pretty pleased with myself. With NRF52 there's always a way. 😎

RE: COMP (or PPI) drops event

Hieu — Mon, 14 Apr 2025 22:23:03 GMT

Hi snoopy20,

Firstly, regarding your conclusion that either PPI or GPIOTE isn't able to keep up with 1MHz COMP, I will have to ask about this in my internal query as well before I can confirm it.

However, I am still unclear on one detail. Does the system run in some kind of loop then? And what is the frequency of looping then?

Secondly, here is my understanding of the system, please correct me if I am wrong.

It is meant to be a UVLO monitoring VDD
The TLV62090 converts VDD to a lower voltage for a sink
The COMP+PPI+GPIOTE setup controls the TLV62090

I think I am missing a few more things:

How the TLV62090 and later circuits affects VDD? Is it just a voltage dip due to sudden loading?
How frequently does this loop repeat?
Can you give a state machine showing how the COMP, GPIOTE, and TLV62090 are supposed to work together?

Thirdly, regarding the RTC workaround you are setting up, could you please tell me exactly which PPI event is connected to which PPI tasks over which PPI channels, one at a time?

RE: COMP (or PPI) drops event

snoopy20 — Mon, 14 Apr 2025 07:02:53 GMT

RE: COMP (or PPI) drops event

snoopy20 — Sun, 13 Apr 2025 19:54:43 GMT

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.

RE: COMP (or PPI) drops event

snoopy20 — Sun, 13 Apr 2025 18:25:15 GMT

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.

RE: COMP (or PPI) drops event

snoopy20 — Sun, 13 Apr 2025 17:38:06 GMT

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)

RE: COMP (or PPI) drops event

snoopy20 — Sun, 13 Apr 2025 10:11:13 GMT

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.

RE: COMP (or PPI) drops event

snoopy20 — Sat, 12 Apr 2025 08:29:18 GMT

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.

RE: COMP (or PPI) drops event

Hieu — Fri, 11 Apr 2025 18:19:28 GMT

Hi snoopy20,

Susheel had to go on a sick leave, and I will support you in his stead.

I will have to ask our IC engineers regarding the question about tolerance variance and the errata. However, please understand that the easter holiday has started, so that might take some time. Our apologies for the inconvenience.

I would like to understand your system a little more.

Does the external circuit react to the edge, or to the level of the GPIOTE signal?
Can it be changed to react to the level of the GPIOTE signal instead? Ideally with some kind time-based debouncing.

For the input signal, is there any chance of jitter? Have you tried to connect the GPIOTE signal and COMP input to a scope and monitor for any incorrect behavior?

RE: COMP (or PPI) drops event

snoopy20 — Tue, 08 Apr 2025 07:35:48 GMT

Same behaviour, the TASKS_SET either didn't fire or was ignored by PPI or GPIOTE.

As I see it the reasoning in both cases has to be one of:

1. the COMP despite being in 'slow' is still able to overwhelm PPI or GPIOTE timing. In a previous post I determined with one of Nordic staff that the 'normal' mode (5MHz) might be pushing it, but 1MHz should be fine for PPI/GPIOTE processing.

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)?

I'm still thinking it's around (1) because switching to 'slow' almost resolved it. I'm thinking there's something around PPI or GPIOTE reaction speed.

This errata says a clock is used for GPIOTE input events > 750KHz. I wonder what clock and whether it also applies for output events...

docs.nordicsemi.com/.../anomaly_810_155.html

RE: COMP (or PPI) drops event

Susheel Nuguru — Tue, 08 Apr 2025 07:16:17 GMT

[quote user="snoopy20"]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.[/quote]

Would have been nice to know why this did not work. What initial triggers missed? or was it after some time that this did not work? There seems to be something we might have missed if this setup did not work. It should have worked.

RE: COMP (or PPI) drops event

snoopy20 — Tue, 08 Apr 2025 06:38:32 GMT

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.

RE: COMP (or PPI) drops event

Susheel Nuguru — Tue, 08 Apr 2025 05:30:32 GMT

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.