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

Custom nrf52840 board (NOT the nRF52840DK), problems using pin 10 as GPIO (i.e. problems disabling NFC)

Hi,

I am having problems with a custom board using pin 0.10 as GPIO.

I have added -DCONFIG_NFCT_PINS_AS_GPIOS to my makefile. Without that, as expected, I am unable to set pin 0.10.

When I do build with -DCONFIG_NFCT_PINS_AS_GPIOS, I am able to set pin 0.10 and see 3.3v, however after a few seconds, it changes to ~0.1v (despite nothing in my application code clearing it).

My application is based on the ble_hrs app and stripped down pretty bare. I can't find anything in config.h that seems related to NFC or pin 0.10. Is there some kind of built-in toggling of the NFC that happens in the softdevice to keep it from conflicting with BLE? Is there something else I should be adding to my config.h, makefile, etc to force off NFC using pin 0.10? Any other ideas of things that could be modifying pin 0.10?

After the first few seconds when pin 0.10 goes to ~0.1v, I still see RTT printouts, I can still connect to BLE, etc.

Thanks!

Jeremy

I'm using SDK 15 with gcc, softdevice 6 and j-link on OSX.

Parents
  • Hi,

     

    My application is based on the ble_hrs app and stripped down pretty bare. I can't find anything in config.h that seems related to NFC or pin 0.10. Is there some kind of built-in toggling of the NFC that happens in the softdevice to keep it from conflicting with BLE?

    No, there is no relation between the softdevice and NFC.

    Is there something else I should be adding to my config.h, makefile, etc to force off NFC using pin 0.10? Any other ideas of things that could be modifying pin 0.10?

    On a custom design, the only thing you need to do is to define CONFIG_NFCT_PINS_AS_GPIOS, then use the pins P0.09 and P0.10 as you would normally. Since you're using nrf52840; you did not route P1.10 instead of P0.10?

    There is one more step you'll need to do if using the nRF52-DK or nRF52840-DK, which is to move two 0-ohm resistors:

    http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52/dita/nrf52/development/nrf52840_pdk/hw_nfc_if.html?cp=2_0_3_7_12

     

    Kind regards,

    Håkon

  • Oh, the comment about P1.10 got me thinking, and I checked the datasheet against my schematic and layout.

    i am using Autodesk EAGLE and the nRF52840 footprint from Nordic’s GitHub repository.

    Looking at my design in EAGLE, it appears several of the pins in that footprint are incorrect. What I routed to is actually P1.09 and not (as labeled in the Nordic provided EAGLE footprint) P0.10:

    eyrie.io/.../a8ad48a1be26430ca63f2aad44afaaaa

    I will check the actual PCB later today, but I’m hopeful because if so I can avoid re-spinning new boards.

    I’m still trying to figure out how I saw any signal at all out of P1.09 (when I was trying to set P0.10). 

Reply
  • Oh, the comment about P1.10 got me thinking, and I checked the datasheet against my schematic and layout.

    i am using Autodesk EAGLE and the nRF52840 footprint from Nordic’s GitHub repository.

    Looking at my design in EAGLE, it appears several of the pins in that footprint are incorrect. What I routed to is actually P1.09 and not (as labeled in the Nordic provided EAGLE footprint) P0.10:

    eyrie.io/.../a8ad48a1be26430ca63f2aad44afaaaa

    I will check the actual PCB later today, but I’m hopeful because if so I can avoid re-spinning new boards.

    I’m still trying to figure out how I saw any signal at all out of P1.09 (when I was trying to set P0.10). 

Children
Related