NRF52832 fault if not connect JLINK RTT viewer

[mokoysh]

Hi  nordic engineer

      I have a product  use nrf52832. And have two project,project use nrf5 17.0.0 SDK and MDK.

     The project A  choose chip nrf52832  and S132

     The project B choose chip NRF52840 and S140 ,and can adapt product 

     There have two problem:

    1、Use the project A firmware, if device not conn jlink RTT viewer, device will restart about 1 day.But if dev conn JLINK RTT ,device not restart. The problem tested many times and many device.

    2、First use project B firmware,device no problem.Then  flash the project A firmware to device and run a period time . Then flash the project B firmware to device ,some device had problem.  Some device start and ble adv,but if use phone connect the adv,device will restart.But  if device start and ble adv after device connected JLINK RTTviewer ,this adv is connectable.

    Both issues are related to JLINK,How to solve this issue?

[Einar Thorsrud]

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

[mokoysh]

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

[Einar Thorsrud]

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

[mokoysh]

Hi 

    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?

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

[Einar Thorsrud]

Hi,

mokoysh said:

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

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

mokoysh said:

    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?

"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