Issues flashing nrf52833 device with v1.8.0 bricking device

RE: Issues flashing nrf52833 device with v1.8.0 bricking device

Einar Thorsrud — Fri, 11 Apr 2025 06:44:04 GMT

Hi,

Perhaps squid can share an update?

Other than that, please make a new thread where you describe the issue you are seeing in more detail (including details about your design and firmware). If you see the device "bricked" after programming, the first things that come to mind is enabling DCDC while lacking the DCDC inductors, or that some signals are somehow connected to the SWD pins and firmware changes makes this surface now, or lastly, that pin reset is enabled and the reset pin is asserted (dependign on configuration, west also when run from VS Code can enable pin reset as that is the default behaviour, which sometimes causes issues).

RE: Issues flashing nrf52833 device with v1.8.0 bricking device

Merrill Wettasinghe — Fri, 11 Apr 2025 00:10:16 GMT

I am having the same problem using the lastest VS code and nRF tools. 2 production board bricked but the dev board is working. I had no trouble with earlier vscode and nrf tools. I am still using 2.5.2 sdk as before.

Can you please share your findings. and if you have made any progress.

I am also using the module from Fanstel with the nRF52833.

RE: Issues flashing nrf52833 device with v1.8.0 bricking device

Einar Thorsrud — Wed, 26 Feb 2025 13:56:24 GMT

Hi Ben,

Thank you. Let us continue in the private ticket for now

RE: Issues flashing nrf52833 device with v1.8.0 bricking device

squid — Fri, 21 Feb 2025 09:21:04 GMT

Hi,

Thanks for the reply. My apologies if it wasnt clear in the previous posts, but once bricked I have not been able to recover. I have followed the instructions elsewhere on the forum to create a script to try to brute force a recovery, but it did not work. I will follow up with a private ticket referring back to this one which includes the mentioned information.

RE: Issues flashing nrf52833 device with v1.8.0 bricking device

Einar Thorsrud — Fri, 21 Feb 2025 08:33:11 GMT

Hi,

I see from the parts of the schematic you shared that VDDH is not used, and that the DCDC inductors are included, so enabling the DCDC should not cause any problems.

The observations that the boards become more or less unrecoverable, but that you sometimes are able to recover by a recover operation in a loop while power cycling is also a bit ambigious. The fact that it sometimes works indicate that firmware plays a part (and that haldting and erasing before a certain step helps, but then I would expect it to always work i the end given enough attempts).

I am also wondering wha tthe difference is bretween what you have build (failign) and your colleague have build before (working). Can you share the zephyr.dts and .config from the build folder for both the working and non-working build? Those will hold the compiled confiugration an ddevicetree that are being used in the end (after all overlays etc are taken into account). Are there any differences there? Also, can you share the full schematic? (You can do that in a private case where you refer to this). Are there any other observations or differences you have seen?

Lastly, can you check if there are any local changes in the code repositories your colleague has compared to what you have? Both for your specific project, but also in the nRF Connect SDK components? (No theck the SDK componnets, I recomen dusing "west status", as that will check the status of all git repositories in the SDK).

RE: Issues flashing nrf52833 device with v1.8.0 bricking device

squid — Tue, 18 Feb 2025 15:21:41 GMT

Hi, thanks for the feedback and taking the time to look into the issue. I will try to answer in order;
- The only difference currently between working and not working is performing a release or debug build inline with .conf files attached in the original post. Flashing the release build with j-flash was working okay, then using the debug build tool in vs code/nrf connect failed/

- Yes 'bricked' ... the device appears to not boot. Not activity can be seen and no attempts to flash/erase/recover is successful. The two config files attached only have two lines diiferent:

CONFIG_OPAL_RELEASE_BUILD=y/n (contextual to build)
CONFIG_BOOTLOADER_MCUBOOT=y/n (contextual to build).

We have meticulously gone through local SDKs for potential differences and have not been able to find anything different from when things worked for the previous developer. Changes to the local sdk are adding the attached defconfig and dts files to \ncs\v1.8.0\zephyr\boards\arm\nrf52833dk_nrf52833\, overwriting prjMCUBoot.conf to \ncs\v1.8.0\bootloader\mcuboot\boot\zephyr\prj.conf and updating \ncs\v1.8.0\bootloader\mcu\boot\zephyr\Kconfig to point to a local .pem key file.

devzone.nordicsemi.com/.../nrf52833dk_5F00_nrf52833.dts devzone.nordicsemi.com/.../prjMCUBOOT.conf devzone.nordicsemi.com/.../nrf52833dk_5F00_nrf52833_5F00_defconfig.txt

I did not design the board, but I understand that 3.3v (2.5-5.5v) to the VDDH pin should enable the high voltage regulator. I did spot another thread along the lines of the DCDC and used a script to repeatedly try to recover the device whilst power cycling. It worked for somebody after ~100 attempts, but unfortunately did not for me.

In neither .conf files is there a reference to DCDC, however I can see in the project build directories it is referenced in a few places for example build\mcuboot\zephyr\.config &build\mcuboot\zephyr\include\generated:

CONFIG_BOARD_ENABLE_DCDC=y
CONFIG_SOC_DCDC_NRF52X=y

Noted on the warnings/errors; as the project was inherited I have not wanted to change things yet as to risk introducing further unknown issues, but I will take a look at tackling the warnings now. The main issue is getting to a point that I can test flashing a device without bricking it.

I think this addresses everything in your reply. Please let me know if you need any further details/info and if you can suggest any changes or tests I can run to prevent further bricked devices.

RE: Issues flashing nrf52833 device with v1.8.0 bricking device

Einar Thorsrud — Tue, 18 Feb 2025 14:29:28 GMT

Hi,

[quote user=""]The first couple of attempts were successful and then the board became unresponsive.[/quote]

Is there any difference between when it worked and when it stopped workign? Did you flash with different firmware, or in a different way, using different tools, or similar?

[quote user=""]where any command line recovery tools timeout with:[/quote]

By being bricked, you are refering tro the unability to recover the device? Could it be that somehow you are usign different board or config files or that there are local changes in one of the SDKs you have checked out?

The reason I ask is that there are two typical issues for seemingly bricking custom boards:

Firwmare that enables the DCDC but the hardware does not have the inductors needed for the DCDC. If that is the case, the device will become unresponsive and impossible to debug after enabling the DCDC.
If using the high voltage regulator, the defult volage after an erase all operation will be set back to 1.8 V unless the UICR is properly programmed with settings for a different voltage.

Of this 1 is probably most likely, so I wonder if you have the DCDC inductors, and if not, if you have configured the project to not enable it? If the DCDC is enabled, you can recover by halding with a debugger imediately after a power cycle, before firmware has time to enable the DCDC (a simple way to do this is to write a small script or similar that calls "nrfjprog --recover" in a loop, while you power-cycle the device until it succeeds (at some point execution should be halted before the DCDC is enabled).

[quote user=""]Debug session build output:[/quote]

This is more of a generic comment, but there is a high number of wearnings in this build, so many that trivial warnings can easily mask imortant ones. I woudl suggest that you work through them and make the code build without warnings.