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 Aidan

    No, this doesn't have anything to have with the DC input to do. But on the DCC pin, there are two inductors and an additional decoupling capacitor that can be connected to use the internal DCDC regulator instead of the LDO regulator (that does not require any external component). However, an application where the DCDC regulator is enabled in code running on HW without these components can unfortunately put the device in an undefined state that brick the device.

    If you'd like we can do a HW review of your schematics and PCB layout files, but I'd recommend opening a private DevZone ticket for that so it is handled with confidentiality and only Nordic engineers and yourself are able to view its contents.

    Best regards,

    Simon

Reply
  • Hi Aidan

    No, this doesn't have anything to have with the DC input to do. But on the DCC pin, there are two inductors and an additional decoupling capacitor that can be connected to use the internal DCDC regulator instead of the LDO regulator (that does not require any external component). However, an application where the DCDC regulator is enabled in code running on HW without these components can unfortunately put the device in an undefined state that brick the device.

    If you'd like we can do a HW review of your schematics and PCB layout files, but I'd recommend opening a private DevZone ticket for that so it is handled with confidentiality and only Nordic engineers and yourself are able to view its contents.

    Best regards,

    Simon

Children
No Data
Related