This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Anomaly similar to PAN #9 in V3 chips

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.

  • 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

  • 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.

  • I can make mine glitch driving a pin with an LED on it. I wondered if it was being pulled high by the pullup (the LED) before the pin is driven down again, I didn't try it on an unconnected pin.

    Seeing if there are any other similarities which might point to the problem, in my case the channel which is glitching is GPIOTE[1] who's TASK is being triggered by PPI[1] and that's being triggered by the timeout EVENT of TIMER2.CH[2]. PPI[0] is also in use, going the other way, capturing a timer value when the pin connected to GPIOTE[0] toggles. There's interrupts enabled too, but I don't see they would affect the hardware PPI. That's basically all of it. It's hard to distill out because the code syncs to the input signal it's capturing, so you need to feed it a square wave, so it's not good for a test case.

  • Mine also uses GPIOTE[1] to assert GPIO[1] triggered by PPI[1] and a compare event on TIMER2.CH[2]; this is a transmit operation. GPIO[1] is cleared in an interrupt handler when the transmit completes. When no transmission is pending GPIOTE[1] is configured to zero and the PPI[1] is re-configured to capture TIMER2.CH[2] on a rising edge of GPIO[28] detected by GPIOTE[0]. And there are other PPIs and GPIOTEs and interrupts and timer channels in use.

    In my attempt to reproduce it I didn't model the timer capture aspect. I'm also pretty skeptical that the fact we're using the same resource instances is anything but coincidental.

    Unfortunately I can't spare more time trying to isolate the fault conditions at this time as the workaround meets my needs.

  • 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.

Related