Anomaly similar to PAN #9 in V3 chips

[pabigot]

PAN #9 in the nRF51822-PAN-v2.4 document provides a workaround for non-functional OUTINIT. This question and this one improve the workaround and state it's unnecessary in V3 chips. Indeed, PAN #9 is not listed in nRF51822-PAN-v3.0.

However, I've observed that with the GPIOTE disabled and the GPIO cleared, configuring an nRF51822 with OUTINIT_Low and POLARITY_LoToHi does sometimes produce a sub-microsecond assertion of the corresponding GPIO exactly coincident with the assignment to the GPIOTE CONFIG register. My suspicion is that the OUTINIT works in V3, but maybe not quite quickly enough.

Applying the PAN #9 workaround appears to eliminate the glitch.

[RK]

Not an answer, but comments are too limited in length.

Thanks for posting this, I found the same thing a few weeks ago on a rev 3 chip with some code which disables and re-enables the GPIOTE attached to a GPIO pin. The GPIOTE was set with OUTINIT to low, trigger Lo->Hi, had been triggered and set the pin high, at which point I disabled it, and set the pin explicitly low again. On re-enabling GPIOTE there's a 1/16,000,000 second, exactly one clock tick, glitch high on the pin before it resets low. I thought initially it was intermittent, but it was actually that I didn't have my logic analyser capturing fast enough, so I only picked it up one time in 10 or something, running the capture at 100MHz, you could see it happened every time and you could see it was exactly 1 HF clock tick wide.

I worked around it a different way - by setting the trigger Hi->Lo, triggering it instantly and then turning the GPIOTE off, when I wanted it back on again, change the trigger back to Lo->Hi and re-enable - with the internal state of the GPIOTE now Low (because of the forced trigger), the glitch went away.

I reported this as an issue, however, although my real code, which uses several GPIOTE, several PPIs and a clutch of timers exhibits the issue totally repeatably, all attempts by me to distill it down to a practical example have failed. The obvious test code, set up one GPIOTE, make a timer trigger it, disable it, force the pin low, next timer tick re-enable it again, doesn't glitch. I tried adding back some of the other elements, PPI, other GPIOTES, but never got a repeatable simple test case and I've currently stopped trying. I think there's some combination of factors which prompts this but I can't find it.

Do you have a practical example which shows this reliably with the rev 3 chip? If you do do you mind opening a support case, referencing mine (case 25105) and sending it in so Hung Bui, who's been very helpful, can have something to work with.

At least I know I'm not going mad

[Hung Bui]

Hi RK&Pabigot,

Thanks for reporting the issue. I will try a little bit more to reproduce the issue from my side. In the mean time, if possible I would suggest you to try on the side the opposite approach to start first with your application, then remove part of it one by one (for example removing PPI[0]). Until you see the glitch is gone. By doing that, hopefully when you are successful to get to the step that the glitch is gone, and then step back one step, we can probably find the peripheral caused the side effect.