NRF52832 fault if not connect JLINK RTT viewer

RE: NRF52832 fault if not connect JLINK RTT viewer

Einar Thorsrud — Wed, 22 Oct 2025 13:33:25 GMT

Hi,

[quote user="mokoysh"]I will modify project A and use new product test and update to SDK17.1.0 test [/quote]

That sounds good. I look forward to knowing if that makes a difference.

[quote user="mokoysh"]

When reflash project A firmware,chip erase chip by JFLASH and recover by nrfjprog .

I guess two problem casued by project A. And the project A modifies the values of certain areas of the chip, such as radio configuration or efuse. It can explain the problem 2. Is there have method to recover the chip?

[/quote]

"nrfjprog --recover" will erase the entierflash and UICR, and there are no fuses, so this means that there will be no trace of firmware A if that is used. So this is strange - could there be a problem with the testing, and that there pattern described where using firmware A causes problem after subsequently programming firmware B, is a red herring?

Br,

Einar

RE: NRF52832 fault if not connect JLINK RTT viewer

mokoysh — Wed, 22 Oct 2025 04:09:16 GMT

When reflash project A firmware,chip erase chip by JFLASH and recover by nrfjprog .

I will modify project A and use new product test and update to SDK17.1.0 test

RE: NRF52832 fault if not connect JLINK RTT viewer

Einar Thorsrud — Tue, 21 Oct 2025 14:00:35 GMT

Hi,

I am having some problems understanding this. Regarding problme 2, where project B firmware works but fails after the device has been running project A firmware. Do you perform a full erase when going back to firmware B? If so, there should not be anything left of firmware A or any persistend data, so that seems odd.

Regarding problem 1, is RTT viewer needed, or is this issue also resolved if you are attached with a debugger, but not an RTT viewer (so not processing the RTT buffer)?

Edit: I also want to stress that you should migrate to SDK 17.1.0 if you are using the latest revision of the nRF52832 as tha thas MDK files that recongnize it. Thait is needed in order to get some errata workarounds applied.

Best regards,

Einar

RE: NRF52832 fault if not connect JLINK RTT viewer

mokoysh — Fri, 17 Oct 2025 06:28:54 GMT

Hi Einar

Thanks reply!

1. I not use NRF LOG but use SEGGER_RTT_printf direct, and the mode is SEGGER_RTT_MODE_NO_BLOCK_SKIP . This log api was used many project and product ,but i will test when close log. And if close ble scan ,the project A no problem.

2. If connected ble advertisment restart chip,reflash project B firmware or recover chip not resolve issue.

Appendix Video, hall trigger ble advertisment/cfs-file/__key/communityserver-discussions-components-files/4/2871d5f6f2f3f8fb1ddfb2144dd1de19.mp4

RE: NRF52832 fault if not connect JLINK RTT viewer

Einar Thorsrud — Thu, 16 Oct 2025 12:49:41 GMT

Hi.

nRF5 SDK 17.0.0 was pulled back shortly after release, and should not be ued. For using older generation devices you can use SDK 17.0.2, but I suggest that you use 17.1.0 as this also supports the latest generatio nRF52832 and nRF52840 devices (see IN-141 and IN-142).

Let us treat this as independant issues for now.

1. As the project runs for one day in both cases, and only fails when RTT viewer is not conneced. Could it be that the RTT log buffer fills up, and the logger is configured to block on full log? Can you check what the value of SEGGER_RTT_CONFIG_DEFAULT_MODE and NRF_LOG_ALLOW_OVERFLOW is set to in your sdk_config.h? Also, does the issue happen if you disable logging alltogether?

2. This seems odd. Did you perform a full chip erase (using for instance "nrfjprog --recover" or "nrfutil device recover"), and still see that firmware B failes after having been programmed with firmware A? Can you double check to see if this is consistent, or if there could have a been a mistake in the testing here? (I am asking as it is difficult to understand how previous firmware could make a difference).

Br,

Einar

RE: NRF52832 fault if not connect JLINK RTT viewer

mokoysh — Wed, 15 Oct 2025 12:27:28 GMT

Additional Instructions the project A use ble scan, if not use ble scan ,device not restart .Use ble scan and connect jlink rttviewer ,device no problem