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

[pabigot]

Yeah, this wasn't really a question, especially as I found a workaround. I just like to report issues through a public forum so others like you can see them and provide clues.

Mine is also deep in proprietary code with a timer triggering a ppi triggering the GPIOTE. I've tried to create a standalone application using timer+PPI+GPIOTE with an LED as the output, and like you failed to reproduce the glitch. The real code runs on a PCA10028 with the GPIO wired to the TX_EN signal of an nRF905; maybe there's some impedance that's necessary to reproduce it.

With two independent reports, at least we can be fairly sure there's a real anomaly.