This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Setting GPIO pull states for the QDEC function in NRF Desktop Gmouse with NRF52840

I am running Version 1.9.1 of the NRF SDK, am programming in VScode, and have written my own custom board and associated DTS files for the hardware we are implementing.

I am trying to initialize a custom implementation of the NRF Desktop Gmouse firmware onto an NRF52840. I have everything else on the board working as expected other than the mouse wheel which is represented by an AB encoder being controlled by the QDEC drivers through zephyr and the NRF Desktop app.overlay files. 

the A and B pins of the encoder are attached to pins P0.08 and P0.06 respectively. I have tested several things but the most recent test I did was soldering in external pull up resistors from the two pins to the NRF supply voltage at which point it worked as expected. With the external pull up resistors removed the encoder does not function correctly. From this I can only assume that somewhere in the initializations for pins 6 and 8 they are set as floating rather than pull up as would be needed for proper functioning of the QDEC/Wheel implementations. 

If anyone can let me know what is going on here and how to resolve it that would be greatly appreciated. I can provide more information if needed though I am not sure what information is productive in this context.

Edit:

Some additional details that I found which may help:

it appears these pins (p0.06/p0.08) are "normally" defined to be the TX and RX part of the UART system when not defined otherwise perhaps this might be where the automatic floating nature of the pins comes from?

I have the AB encoder set up with A connected to pin p0.06 and B connected to pin p0.08 with the common pin on the encoder connected to GND of the circuit. as seems to be indicated by the circuit diagram. Additionally I have built an earlier revision of this board with the QDEC A-pin connected to P0.09 and the b-pin connected to P1.06 and it functions correctly measuring sequential encoder movements. 

Additionally the enable pin defined in the QDEC is connected to an arbitrary unused pin that does not seem to have any impact on this issue, I also tried pulling the enable pin high or low and there was no difference. the LED-pin is 0xFFFFFFFF and the LED-pre setting is 0 as copied from the earlier version of my code which was based on the original gmouse code.

Edit Again:

I did more investigating, The encoder works as expected (recording all rotations) when two 10k pull ups are connected to the pins of the encoder. I probed the A and B pins on the encoder relative to the common pin (ground) and found that they alternate between ~13mV and 0mV depending on the position of the encoder as expected (though the voltage seems very low).

Comparing that to my previous version of the board: the A-pin (P0.09) measures 0.152V when open and B pin(P1.06) measures0.018V  when open, both of the pins measure 0V when the encoder is in the other state as expected.

Update:

My older implementation only rotates one direction even if the encoder is spun the other way so it appears that the 0.018V B pin is not correctly being recorded.

  • Hi Tynan

    Are you using a different encoder from the reference design?

    Some encoders might require pullups while others do not. 

    I will have to get back to you on the best way of enabling pullups with the existing driver. In the next NCS version this will be significantly easier, because of the new pinctrl system that is being implemented (the main purpose of pinctrl is to allow dynamic configuration and reconfiguration of pins, which is not currently possible). 

    Best regards
    Torbjørn

  • Hi Torbjørn,

    From what I can tell the encoder being used is an incremental encoder similar to the relatively standard Kailh wheel encoders.

    I was not aware of a reference design for this implementation would it be possible to point me to that?

    Glad to know that a newer driver is in development, Knowing that pull ups are likely required I will implement this for the time being.

  • Resolution:

    After much digging I have discovered you can use the QDEC LED pin as a GPIO pin that provides the "pull up" for the two QDEC pins which will automatically power down and not constantly draw current unlike using a standard pull up resistor connected to VDD.

  • Hi Tynan

    Sorry for the missing response, I was caught up in some other projects. 

    Good to hear you found a solution, and thanks a lot for sharing it here Slight smile

    Best regards
    Torbjørn

Related