nRF52833 chips are consistently becoming bricked and un-programmable via SWD

Hi folks,

I'm attempting to program an nRF52833 using a Segger J-Link+ connected to the SWD program/debug pins on the board.The board is only an nRF52833 - as a learning exercise, I printed a PCB that extends the pins on a QFN40 package to standard 2.54mm spaced pins. I'm powering the board using a 3.3V power supply, and using the 3.3V input as the VRef for the J-Link. The programming itself is being done via Segger JFlashLite, over SWD, at 4000 kHz. The software being uploaded is a .hex file provided by Qorvo for product of theirs that utilizes with an nRF52833 (the DWM3001C chip). I have a total of 5 of these boards.

At first, when I program the board, everything is successful. JFlashLite confirms that the programming succeeded and I'm able to interact with the board over UART (as is expected from the program uploaded). After some amount of re-programming (after modifying the software), normally between 5 and 10 times, the J-Link stops being able to connect to the board and consistently encounters the error "Unable to connect to target" when attempting to program. When I attempt to connect to the board using JFlashExe to debug, it also fails with the error "Unable to connect to target". This has now happened to all 5 of my boards, and once they enter this state they appear to be bricked - they cannot be re-programmed and they cannot be interacted with over UART. Upon further inspection, I've discovered that one of the traces in my breadboard has a spotty connection and occasionally doesn't correctly connect the JLink SWD_CLK/SWD_IO pins to the corresponding pins on the board, if that has any significance (I have since tried programming the boards in different locations and they're still bricked).

I've attempted to use nrfutils to recover the device as per this doc page: https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-device/guides/programming_recovery.html, but this also fails with an error suggesting that the JLink is unable to connect to the target device. I have also attempted cycling the RESET pin high & low while programming and this also does nothing to recover the board.

At this point, I'm at a loss. I'm particularly confused because the programming does appear to work most of the time, but occasionally it ends up in this corrupted state that I can't appear to recover from. Any support on how I could recover these would be much appreciated. Cheers.

Parents
  • Hi

    Just to confirm, when you say the board is "only an nRF52833", can you confirm that you've also included the required components from the reference circuitry. If the decoupling capacitors and 32MHz crystal I.E. aren't connected to the nRF52833, it's not expected to work as intended. You might be able to flash it, but whatever is flashed onto it won't work as expected.

    If you have the required components, another thing causing something like this could be if you don't have the DCDC components on your hardware, but the software enables the DCDC regulator. That will also result with a bricked nRF52 I'm afraid.

    Best regards,

    Simon

Reply
  • Hi

    Just to confirm, when you say the board is "only an nRF52833", can you confirm that you've also included the required components from the reference circuitry. If the decoupling capacitors and 32MHz crystal I.E. aren't connected to the nRF52833, it's not expected to work as intended. You might be able to flash it, but whatever is flashed onto it won't work as expected.

    If you have the required components, another thing causing something like this could be if you don't have the DCDC components on your hardware, but the software enables the DCDC regulator. That will also result with a bricked nRF52 I'm afraid.

    Best regards,

    Simon

Children
  • Thanks Simon. I can confirm that I do have the decoupling capacitors & 32MHz crystal.

    You'll have to forgive me, I'm quite new to this. Could you please elaborate further on this:

    > If you have the required components, another thing causing something like this could be if you don't have the DCDC components on your hardware, but the software enables the DCDC regulator. That will also result with a bricked nRF52 I'm afraid.

    I think you're suggesting that this could happen if the chip is receiving un-regulated DC input (i.e not stepped down to 3.3V)? Or am I mistaken.

    Cheers,

    Aidan

Related