Custom Board nRF52840 Some Pins Not Working

I am diagnosing pin malfunction in a custom board where I have working code from another version of the board which no longer works.

I am developing against NCS w/ VSCode and extensions.

I am moving from one custom board to another, where the old board used a BT840 pre-made nRF52840 module (the nRF52840, plus caps, crystals, etc) to a board where I place the nRF52840 chip myself along with caps, crystals, etc.  My newest custom board was fabricated by JLCPCB within their tolerances.

The nRF52840 is the QIAA / aQFN73 version.

The inner ring of pins, where used, I drop to the bottom layer with a via, and route from there.

My problem is that some, not all, of the pins that are in the inner ring don't appear to be working.  This may well be coincidence that they're in the inner ring.

When I say they don't work, I mean bringing the pin high/low in software does not electrically influence the voltage on the trace.

As noted, I have working software from a prior version of this board, where instead of a direct aQFN I used a pre-made module.

So my thinking is there is either some differences between the module behavior and mine, or a physical manufacturing problem.  I for sure know there are some differences I have to account for in software, such as this part appears to be a newer nRF52840 and requires changes in accordance with more recent APPROTECT behavior (link) and (link), as well as DC/DC changes (link) so I'm open to the idea there is more I have to account for.

I have unsoldered the chip on one board and confirmed end-to-end continuity from the pin pad to the endpoint of the trace.  I have reached out to JLCPCB to see if they believe the board is out of spec or otherwise susceptible to failure and am awaiting reply.

My question to Nordic is, is there something I might be missing moving to a DIY module?  How can I investigate?

I have followed the Nordic reference circuitry exactly, specifically the (link) specification's 7.3.3 reference layout.  First image from the Nordic pdf reference, second from KiCad schematic editor.

I have also followed the footprint layout suggested on p. 609

The specific pins which appear to be not working are:

  • M2 / 0.07
  • P2 / 0.23
  • AC19 / 0.25
  • AC21 / 1.08

It may well be possible other power-related pins aren't working and I simply don't know.

Please help me work through diagnosing this.

Thanks.

Doug

  • Hi Doug,

    can you upload the HW files, altium or gerber? 

    Does you the code that worked on the other board not work at all, our is it just the four pin's?

    Does your code work on our DK?

    Best regards,
    Kaja

  • Hi,

    Here are the gerbers.

    BikeControlBoardNRF-5v-gerbers.zip

    Does you the code that worked on the other board not work at all, our is it just the four pin's?

    Just those 4 pins aren't responsive to software.  The code is running otherwise.  Other pins are responsive and work as before.

    Does your code work on our DK?

    I didn't try. But it does work on another custom board, and an earlier version of the software worked on the Adafdruit nRF52840 Feather (I subsequently moved to a custom board as development continued).

    To give an example of what stopped working - I have (AC19 / 0.25) configured to be UART0 TX in my overlay file and that works in my old custom board.  Moving to the new custom board, same configuration, same nRF52840 pin, but the signal isn't measurable at the exposed header.

    If I reconfigure my overlay to route UART0 TX to a different pin (L1 / 0.06), I can measure that signal there.

    The software is no different between the two configurations.

    Thanks.

  • Hi,

    just to rule out any possible reasons for this to be dependent on your fw, can you flash this bare metal example to your board, measure directly on the pad and see if you can measure a toggling signal? You need to set PIN_GPIO to the pin that you want to test. For example for pin 0.07, PIN__GPIO = 7UL. Just add the code to the hello_world sample in Zephyr.

    /*
     * Copyright (c) 2012-2014 Wind River Systems, Inc.
     *
     * SPDX-License-Identifier: Apache-2.0
     */
    #include <zephyr/zephyr.h>
    #include <nrf.h>
    //define the pin that you want to toggle here
    #define PIN_GPIO  (13UL)
    int main(void)
    {
      // Configure GPIO pin as output with standard drive strength.
      NRF_GPIO->PIN_CNF[PIN_GPIO] = (GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos) |
                                    (GPIO_PIN_CNF_DRIVE_S0S1 << GPIO_PIN_CNF_DRIVE_Pos) |
                                    (GPIO_PIN_CNF_INPUT_Connect << GPIO_PIN_CNF_INPUT_Pos) |
                                    (GPIO_PIN_CNF_PULL_Disabled << GPIO_PIN_CNF_PULL_Pos) |
                                    (GPIO_PIN_CNF_SENSE_Disabled << GPIO_PIN_CNF_SENSE_Pos);
      // Toggle GPIO ON/OFF.
      while (1)
      {
        uint32_t volatile tmo;
        tmo = 10000000;
        while (tmo--);
        NRF_GPIO->OUTSET = (1UL << PIN_GPIO);    
        tmo = 10000000;
        while (tmo--);
        NRF_GPIO->OUTCLR = (1UL << PIN_GPIO);  
      }
    }

    How many boards are you seeing this issue on? What percentage?

    Best regards,

    Kaja

  • Hi, the code you provided results in the same observations as before, that is, pins which aren't functioning.

    I am seeing this problem on at least 8 boards of a batch, never seeing any work (I stopped checking new ones after a while).  I have even found another pin (0.16) which isn't working (in addition to the others) on the last board I tried.

    I am thinking there is a PCB Assembly problem.  I am reaching out to JLCPCB to find out more.

    If you have any other thoughts on what I could check I would pursue that as well.

    Thanks.

  • What is the components in the red circles? 



    What happens if you disconnect these components? 

    Can you share the full schematic? 

    Best regards,
    Kaja 

Related