nrf52840-DK won't boot, isn't visible through File Explorer or J-Link

Pretty new to development, compiled and flashed Zephyr basic samples through nrf Connect for VS Code (board type: nrf52840dk_nrf52840) and suddenly board wouldn't respond anymore (LED5 won't light up, isn't accessible through File Explorer or J-Link Commander). Unfortunately I don't remember exactly which hex file I programmed other than it being a Zephyr sample, apologies. Here are the troubleshooting steps I have attempted and their results:

Does the device show up in Device Manager on your computer? Please try to connect and disconnect the kit a few times. It might show up with unexpected names. 
Device does not show up in Device Manager, nor is any USB connection / disconnection sound noticed when plugging and unplugging from the computer.

Have you tried a different USB cable? Faulty cables are surprisingly often the problem.
Have tried three different USB to micro-USB cables - cable doesn't seem to be the issue since my nrf51-DK works perfectly fine.

Have you tried using a different computer? If it works on a different computer we know that the kit is not broken and that it is probably a driver issue.
Yes, different computer does not work either - still isn't detected.

Have you tried to press the IF BOOT/RESET button while power cycling the kit? It should then show up as a Removable Storage Device named "BOOTLOADER". Then you can drag-and-drop the J-LINK interface MCU firmware found here (v170724) onto the storage device to reprogram the JLINK firmware.
Power cycling the kit while pressing the IF BOOT/RESET button in Li-Po/USB does not give any response other than LED1-LED4 blinking very rapidly. Setting power to VDD does not give any response whatsoever. Have also tried switching between nrf ONLY / DEFAULT for the switch at the long side of the board. Thus cannot access the BOOTLOADER folder to recover.

- Have you measured the supply voltage on the kit? It should be somewhere between 2.8V-3.3V. If it isn't, then the hardware is probably broken.
Supply voltage (from VDD to GND) on USB or Li-Po power settings is 2.7V, VDD power setting is 3V.

Have you made sure that you are using the latest J-Link driver version?
Yes, have already tried updating including completely uninstalling and reinstalling the driver.

Have you tried this guide? https://devzone.nordicsemi.com/blogs/.. 
Yes, the board isn't recognized through J-Link Commander so cannot make any connection.

If on step 4 the kit does not show up as "BOOTLOADER", try to download and install the mbed Windows serial port driver from here: http://developer.mbed.org/media/downloads/drivers/mbedWinSerial_16466.exe 
Cannot install driver since no mbed connections were found.

  • Hi,

    Which revision of the nRF52840 DK do you have? Can you share a photo of it as it is currently being used on your desk? Have you done any modifications to it?

    compiled and flashed Zephyr basic samples through nrf Connect for VS Code (board type: nrf52840dk_nrf52840) and suddenly board wouldn't respond anymore

    Communication between the PC and the debugger via USB should not be affected by any firmware running on the nRF. Are you sure this issue started with programming a sample? If so, I wonder if you have modified the DK in some way, perhaps accidentally connected some GPIOs to  the SWDIO or SWDCLK pins? This is also something I wonder about because of this:

    Power cycling the kit while pressing the IF BOOT/RESET button in Li-Po/USB does not give any response other than LED1-LED4 blinking very rapidly.

    LED5 is connected to the debugger, but LED1-LED4 is connected directly to the nRF only. So there is no natural way these LEDs should react because you are trying to put the nRF in bootloader mode (except if they always heave a specific way after reset, and you reset the nRF in the process). So that is the first question. Do you see the same on LED1-LED4 by simply just pushing the reset button, or after a power-cycle? If not, something externally is happening. Could one or more of the LEDs be shorted with the SWDIO and/or SWDCLK pin on your board for some reason?

  • Hi Einar, thanks for the quick response.

    Not sure about the exact revision of the nrf52-DK - the Mouser part number is 949-NRF52840-DK and the sticker on the board says "PCA10056 - 3.0.0 - 2022.20 - 1050254988" (I'm assuming that's revision 3 but could be wrong). I don't believe the board stopped working directly as a result of flashing the examples, but the board worked perfectly well beforehand just plugged in and not doing anything. I don't have any wires or anything connected to my nrf52840-DK as of this moment, and the LED1-LED4 flashing specifically happens after power-cycling in the USB and LiPo positions, pressing the reset button normally has no response whatsoever.

       

  • The LED1-LED4 rapid flashing also persists after a regular power cycle, but drops after switching power modes to VDD (the flashing continues if the power setting switch is changed rapidly enough from LiPo to USB and vice versa, but drops if the power setting lingers on VDD for too long, the board doesn't seem to be getting power during VDD for some reason.

  • Hi,

    You have revision 3 of the DK, which has a nRF5340 as debugger, so many of the advice you found originally does not apply to this debugger (you cannot replace the debugger firmware by putting it in bootloader mode after pushing reset while power cycling, for instance).

    And the way you describe it now it seems you have a form of blinky app running, and that continue to work (LEDs blink) and this issue happens later, so it seems somehow related to powering of the DK or nRF. As you supply the board via the USB cable on the left side (connected to the debugger), the correct position of the nRF power source switch is VDD. So as long as the switch is kept at VDD position (middle), this should work. You also need the SW6 switch to be set to DEFAULT (right position) in order to use the debugger.

    If correcting the switch positions does not work, and you have attempted another USB cable and another computer, then perhaps there has been some damage to some components. As you describe that manipulation the nRF power source switch helps that is a primary suspect. Can you double-check that this is indeed the problem?

Related